Red Hat Bugzilla – Bug 239678
connectathon op_chmod test fails when run against win2k3 server
Last modified: 2009-02-17 13:06:15 EST
This test seems to reliably work when run against samba, but fails when run
In one shell run a perl script like this on a CIFS filesystem mounted on win2k3:
open(FILE, ">testfile") or die("Can't open testfile\n");
print("Hit return to continue\n");
...in another shell, chmod 0 testfile and then attempt to delete it. It will fail:
unlink("testfile") = -1 EACCES (Permission denied)
If you don't chmod the file, or if the file isn't open then it works.
If the file is open on the client and no write bits are set then trying to
unlink the file throws back an EPERM. My guess is that this is setting the
ATTR_READONLY dos attribute on the server and that's what's causing it. On samba
w/o unix extensions enabled, it allows the file to be removed.
Ok, having another look at this. We attempt to delete the file, and if it fails
then we open the file and set the delete on close bit, and try to rename it.
I don't think that you can legally set the delete_on_close bit in an open call
unless you're actually creating the file at the same time. JRA explained this to
me at connectathon. Samba apparently ignores this bit unless you're creating the
file. I think if we do a SET_FILE_INFO call with this bit set then that may
work. This is something that needs fixing anyway...
I hacked up a quick patch to not set the delete on close bit in the CreateAndX
call, and instead to set it with a SetFileInfo call. Everything works as it should.
I don't want to just add this code in, however. The cifs_unlink code needs some
cleanup. There's a lot of cut and paste work in there and it's heavily indented
already. Once my I get my setattr cleanup upstream, I'll plan to take a crack at
this and see if we can fix it.
*** Bug 446147 has been marked as a duplicate of this bug. ***
Patchset pushed upstream to fix this. Awaiting comment...
Patchset went upstream. Closing as duplicate of cifs update BZ.
*** This bug has been marked as a duplicate of bug 465143 ***