Bug 3858 - hide unreadable together with wildcard operations fail
hide unreadable together with wildcard operations fail
Product: Samba 3.0
Classification: Unclassified
Component: File Services
x64 Windows 2000
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-06-26 05:30 UTC by Andreas Octav
Modified: 2006-06-26 18:46 UTC (History)
1 user (show)

See Also:

Patch (1.62 KB, patch)
2006-06-26 18:33 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Octav 2006-06-26 05:30:48 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 =
        force create mode = 770
        comment = sapclassic
        hide unreadable = yes
        path = /data/EMPFS/sapclassic
        read only = No
        browseable = Yes

Kind regards,
Andreas Octav
Comment 1 Jeremy Allison 2006-06-26 11:22:56 UTC
I'll check this problem out for 3.0.23. Thanks.
Comment 2 Jeremy Allison 2006-06-26 16:09:50 UTC
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
"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
Comment 3 Jeremy Allison 2006-06-26 16:10:54 UTC
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 ?
Comment 4 Jeremy Allison 2006-06-26 17:39:43 UTC
I've reproduced the problem in SAMBA_3_0, investigating...
Comment 5 Jeremy Allison 2006-06-26 18:33:13 UTC
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.....

Comment 6 Jeremy Allison 2006-06-26 18:46:46 UTC
Bug is now fixed - please merge for 3.0.23.