The Samba-Bugzilla – Bug 3858
hide unreadable together with wildcard operations fail
Last modified: 2006-06-26 18:46:46 UTC
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 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
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
force create mode = 770
comment = sapclassic
hide unreadable = yes
path = /data/EMPFS/sapclassic
read only = No
browseable = Yes
I'll check this problem out for 3.0.23. Thanks.
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
"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.
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 ?
I've reproduced the problem in SAMBA_3_0, investigating...
Created attachment 1986 [details]
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.....
Bug is now fixed - please merge for 3.0.23.