Bug 2227 - No Error Message When Deleting Files From Windows XP SP2 Workstation
Summary: No Error Message When Deleting Files From Windows XP SP2 Workstation
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.11
Hardware: x86 Windows XP
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
: 1886 2141 (view as bug list)
Depends on:
Reported: 2005-01-07 11:56 UTC by Andrew Merkert
Modified: 2005-08-24 10:16 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Merkert 2005-01-07 11:56:45 UTC
Running Samba version 3.0.9-1.3E.1 on Redhat Linux 3.0 ES (Kernel version:  
2.4.21-20.EL).  Linux file system (ext3 with ACL support) has the following 
directory structure:


The permissions for testdir1 are as follows:

# file: testdir1
# owner: root
# group: tp39328

The permissions for testfile1 are as follows:

# file: testfile1
# owner: root
# group: tp39328

A user who connects to the Samba server via a Windows XP SP2 workstation who 
is a member of the tp39420 group, but not the tp39328 group, are seeing a 
problem if they try to delete the testfile1 file.  The OS attempts to remove 
the file, it is removed from the explorer window with no error messages 
generated.  However, if you then click on F5 to refresh the explorer window, 
the file re-appears.  Also, if you try to delete the file from the command 
prompt window, no error message is provided, but the file is untouched.

If I attempt this same action on a Windows 2000 SP4 workstation, I am 
presented with an error message indicating that the attempt to remove the file 
is not allowed due to an access violation. 

Would like to see the Windows XP SP2 users receive a similar error message to 
eliminate confusion for my end-users.  I am unable to test this on a Windows 
XP SP1 workstation.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2005-02-09 06:07:05 UTC
very strange.  reproduced against 3.0.11
Comment 2 Jeremy Allison 2005-02-10 14:37:18 UTC
Ok, this happens as the client opens the file with DELETE access requested and
then sets the delete on close bit. This must be new behaviour with XP SP2. We
allow the open (as we'd need to check the parent directory at open time) and
then ignore the setting of delete on close. This is a bug, but it's going to be
difficult to fix as the Windows semantics are that the file needs to appear in
the directory listing until the close - which it won't do if we delete on the
SETFILEINFO call.... Hmmm. Need to think more about this...
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-02-11 09:08:29 UTC
jeremy checked in a change for this.  should be fixed in 
the latest 3_0 svn.  Patch available at 

Comment 4 Jeremy Allison 2005-02-11 11:14:50 UTC
No, I haven't fixed it *yet*. I just checked in the framework for more code.
I'll close it myself when I *really* fix it (and the commit message will say
"fixed bug #2227" also :-).
Comment 5 Jeremy Allison 2005-02-11 18:08:46 UTC
I have now fixed this in SVN (as well as it can be done with POSIX anyway :-).
Please test this with your ACL set up.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-02-17 09:26:29 UTC
*** Bug 2141 has been marked as a duplicate of this bug. ***
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-02-19 09:33:58 UTC
*** Bug 1886 has been marked as a duplicate of this bug. ***
Comment 8 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:16:01 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.