Project

General

Profile

Actions
Copy link

Bug #2416

open

'.' entry can be removed on mounted nfs filesystem

Added by ftigeot about 12 years ago. Updated over 10 years ago.

Status:
New
Priority:
Normal
Assignee:
tuxillo
Category:
VFS subsystem
Target version:
3.9.x
Start date:
09/01/2012
Due date:
% Done:

0%

Estimated time:

Description

I use a shared /usr/pkgsrc/packages on various DragonFlyBSD machines

Just after doing a "rm *" to remove accumulated cruft in packages/All
on a client machine, I noticed the "." entry had disappeared.

On the client machine I typed the command on, ls(1) only shows a unique '..'
entry in /usr/pkgsrc/packages/All. /usr/pkgsrc/packages doesn't
contain a '.' entry anymore. None of its subdirectories do.

On other client machine, the '.' entry has also disappeared from
/usr/pkgsrc/packages and all its subdirectories.

The server still contains '.' and '..' entries in the exported directory and
all its subdirectories.

Clients and server machines are all running DragonFly-3.1.
mount points and all of is

Actions
Copy link
 #1

Updated by tuxillo over 10 years ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Assignee set to tuxillo
  • Target version set to 3.9.x

Hi François,

You didn't actually remove ".", obviously. The problem is that the NFS server is not providing that directory entry at all (not sure if this comes from readdir or where else) for the getdirentries(2) syscall. ktrace to ls -a shows (remember we no longer show files starting with dot if -a parameter isn't passed to ls):

$ ktrace -i ls -a /home/antonioh/testbug/
..

$ kdump -af ktrace.out
[...]
28060 2 ls 0.000002 CALL getdirentries(0x4,0x800751000,0x1000,0x7ffffffff108)
28060 2 ls 0.058455 RET getdirentries 24/0x18
28060 2 ls 0.000000 CALL lseek(0x4,0,0,SEEK_CUR)
28060 2 ls 0.000008 RET lseek 512/0x200
28060 1 ls 0.000012 CALL getdirentries(0x4,0x800751000,0x1000,0x7ffffffff108)
28060 1 ls 0.000007 RET getdirentries 0
28060 1 ls 0.000006 CALL lseek(0x4,0,0,SEEK_SET)
[...]

It can't be the nresolve code (checked this with dillon, too) because the dir entry is shown when explicitly specified:

$ ls -ld /home/antonioh/testbug/.
drwxr-xr-x 1 antonioh antonioh 0 3 jun 13:34 /home/antonioh/testbug/.

The problem must lay within the NFS server because mounting /home from a Linux server does show the "." entry:

$ ls la /mnt
total 12
drwxr-xr-x 4 root wheel 4096 28 mar 18:48 .
drwxr-xr-x 1 root wheel 0 2 jun 12:46 ..
drwxr-xr-x 3 root wheel 4096 28 mar 18:48 .ecryptfs
dr-x----- 2 antonioh antonioh 4096 28 mar 18:48 antonioh

Best regards,
Antonio Huete

Actions
Copy link

Also available in: Atom PDF