Hide Forgot
This test seems to reliably work when run against samba, but fails when run against windows2k3. 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"); <STDIN>; ...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 ***