Setting "hide unreadable = yes" prevents Clients from deleting or renaming files when using wildcards (e.g. del *.*) on directories with a lot of files. Only the first ~150 files get processed. The rest of the files stays untouched. If "hide unreadable" is not used all files get removed or renamed. Server OS is SuSE SLES 9 x64 SP3. The problem occurs even in a simple configuration (see smb.conf below) without using ACLs or LDAP. smb.conf: # smb.conf is the main Samba configuration file. You find a full commented # version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the # samba-doc package is installed. # Date: 2005-12-01 [global] workgroup = EMPFS map to guest = Bad User security = user encrypt passwords = true smb passwd file = /etc/samba/smbpasswd username map = /etc/samba/smbusers netbios name = vessnt32 netbios aliases = interfaces = 10.16.30.12/16 [sapclassic] force create mode = 770 comment = sapclassic hide unreadable = yes path = /data/EMPFS/sapclassic read only = No browseable = Yes Kind regards, Andreas Octav
I'll check this problem out for 3.0.23. Thanks. Jeremy.
Hi Jeremy, it seems that the macro SMB_VFS_STAT in smbd/dir.c fails (line 856; function "user_can_read_file") after working fine for several files. The amount of files that get correctly processed seems to be connected to the length of the filenames. I created 200 files with names like 1,2,3 and so on and about 150 files got deleted. As i changed the filenames to something like "1.iguhreignignegjerjgnrkejnlgnrenlgrejwgreöldlklsdkdkgsj", "2.iguh......." and so on only around 80 files got deleted by a "dir *.*". Hope this helps you a bit tracking down the problem... By the way: In 3.0.23 the behaviour described above is the same. Best regards, Andreas Octav
Andreas -can you tell me about the contents of the directory ? Are any of the files actually unreadable by the user doing the delete ? Or are they all readable by the deleting user ? Jeremy.
I've reproduced the problem in SAMBA_3_0, investigating... Jeremy.
Created attachment 1986 [details] Patch This one is really interesting. The pattern of deleting a directory is to do a findfirst to get the first part of the list, then for each name returned it does a open/set delete on close/close -> thus deleting the file. Then it does a findnext with the last file name THAT IT JUST DELETED ! Now we can handle this in the findnext in the case where hide unreadable is set to false as we look back in our cache of names and just seek to the right point. The bug is actually fixed in the first hunk of this patch - the one that removes the is_visible_file() check after SearchDir returns false. We don't actually need it and in this case it's causing the delete to be aborted because it can't find the name (doh ! it was just deleted). We don't need it as SearchDir is only ever called from findnext, and findnext should only ever be returning names we gave it. Phew - that one took a while to track down..... Jeremy.
Bug is now fixed - please merge for 3.0.23. Jeremy.