Bug 3216 - Deleting of folders doesn't work (they reappear after a refresh)
Deleting of folders doesn't work (they reappear after a refresh)
Product: Samba 3.0
Classification: Unclassified
Component: File Services
x86 Windows XP
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
: 3213 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-10-26 05:38 UTC by Walter Haidinger
Modified: 2005-11-03 11:31 UTC (History)
1 user (show)

See Also:

packet trace (3.84 KB, application/octet-stream)
2005-10-26 08:28 UTC, Ahmon Dancy
no flags Details
Patch against 3.0.20b (3.04 KB, patch)
2005-10-27 18:08 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Walter Haidinger 2005-10-26 05:38:03 UTC

I recently discovered that I cannot delete folders using Windows anymore.
Actually, the folder _seems_ to be correctly deleted if done with Windows
Explorer (i.e. it is removed from the list), but it reappears after a refresh
(using the F5 key).

Only directories are affected, i.e. I can remove all plain files without problems.

Tried this with Windows XP Pro SP1 and SP2 (one without any patches and another
with all but the most recent updates of Oct. 2005) installations.

Please note that everything works using smbclient connecting to with the same
share with identical user and password, i.e. rmdir succeeds and the folder
is gone, as well as a rmdir as the same user natively under Linux.

Also, very interesting: Using cygwin, a 'cd //server/share && mkdir foo && rmdir
foo' fails with rmdir: 'foo': Directory not empty.

Unfortunately, I do not know for sure when this bug was introducted. I _think_
everything worked with 3.0.20a because it is unlikely that that I just did not
notice before.

Speaking of versions: I'm running Samba-3.0.20b under SuSE 9.3 with a self-built
vanilla kernel. Samba was installed using the binary (please don't stop
reading here!) packages from:

WAIT! Because the binary package did not work, I recompiled the samba-3.0.20b
tarball from samba.org using the configure options ripped from the SuSE
source rpm:

./configure --prefix=/usr --sbindir=/usr/sbin --localstatedir=/var/lib/samba
--sysconfdir=/etc/samba --with-configdir=/etc/samba --with-libdir=/usr/lib/samba
--with-lockdir=/var/lib/samba --with-logfilebase=/var/log/samba
--with-mandir=/usr/share/man --enable-cups --with-acl-support --with-automount
--with-msdfs --with-pam --with-pam_smbpass --with-piddir=/var/run/samba
--with-privatedir=/etc/samba --with-quotas --with-smbmount
--with-swatdir=/usr/share/samba/swat --with-syslog --with-tdbsam --with-utmp
--with-vfs --with-winbind --with-shared-modules=idmap_rid,idmap_ad
--with-expsam=xml,mysql,pgsql --with-python --with-fake-kaserver=auto && make &&
make install

Unfortunately the bug remained and that's why I'm creating this bug entry 
rather than contacting SuSE.

FYI, I cannot recall any changes in my Samba configuration that would 
justify such odd behaviour. Moreover, I'm using the shares for quite some
time now (say, since Samba 2.0.x) and they always worked.

My Samba configuration:

        security = user
        client NTLMv2 auth = Yes
        client lanman auth = No
        client plaintext auth = No
        null passwords = Yes
        guest account = smbguest
        username map = /etc/samba/smbusers
        log level = 5
        syslog = 0
        log file = /var/log/samba/%m.log
        max log size = 25000
        name resolve order = hosts wins lmhosts bcast
        time server = Yes
        os level = 65
        lm announce = No
        preferred master = No
        domain master = No
        wins proxy = No
        wins server =
        create mask = 0740
        directory mask = 0750
        max connections = 100
        hide special files = Yes
        dont descend = /proc,/dev,/root,/etc

        comment = Test Directory
        path = /home/walter/testdir
        valid users = walter, root
        force user = walter
        read only = No
        create mask = 0750
        hosts allow = 192.168.
        hide dot files = No

A level 10 logfile is available from:

It contains the creation of folder 'foo1' and the failed attempt
of deleting it.

If you need any other information to trace this problem, I'd be happy to supply!

Regards, Walter
Comment 1 Gerald (Jerry) Carter 2005-10-26 05:48:44 UTC
*** Bug 3213 has been marked as a duplicate of this bug. ***
Comment 2 Ahmon Dancy 2005-10-26 08:26:41 UTC
I am attaching an ethereal packet trace of the transaction when attempting to
rmdir an empty directory in a cygwin shell.
Comment 3 Ahmon Dancy 2005-10-26 08:28:41 UTC
Created attachment 1540 [details]
packet trace

This is the packet trace during an attempted rmdir of an empty directory when
using a cygwin shell.
Comment 4 Jeremy Allison 2005-10-27 13:33:50 UTC
Ok, I know what this is. Cygwin is using a set of the delete on close flag of an
empty directory to remove an empty directory. This doesn't work with the new
locking changes.
I'll fix it.
Comment 5 Jeremy Allison 2005-10-27 18:08:08 UTC
Created attachment 1547 [details]
Patch against 3.0.20b

Try this patch against 3.0.20b - it's equivalent to what is going into 3.0.21
to fix this. Please let me know if this fixes the problem.
Comment 6 Walter Haidinger 2005-10-28 06:04:38 UTC
Works! :-)

I recompiled the SuSE 3.0.20b source RPMs with the patch applied.
Can delete empty directorys from Cygwin _and_ Windows Explorer.

One question, though: 
If this is a Cygwin "bug", then why is the Windows Explorer affected too? 

Anyways, worksforme now but I think the bug can be resolved as fixed now.
Comment 7 Michael Arlt 2005-11-03 06:54:32 UTC

we had the same problem when we delete folders using windows explorer. Now with
the patch applied everything is ok.

Thanks for the patch,

Comment 8 Walter Haidinger 2005-11-03 07:09:16 UTC
Jeremy, can this bug be resolved as FIXED now?

Regards, Walter
Comment 9 Jeremy Allison 2005-11-03 11:31:08 UTC
Bug is now fixed.