Bug 5790 - samba returns STATUS_OBJECT_NAME_NOT_FOUND on set file disposition call
Summary: samba returns STATUS_OBJECT_NAME_NOT_FOUND on set file disposition call
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.1
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-24 07:29 UTC by Jeff Layton
Modified: 2008-09-26 23:32 UTC (History)
3 users (show)

See Also:


Attachments
log from samba during reproducer with log level set to 10 (22.63 KB, application/octet-stream)
2008-09-24 07:31 UTC, Jeff Layton
no flags Details
binary capture from same reproducer (3.42 KB, application/octet-stream)
2008-09-24 07:32 UTC, Jeff Layton
no flags Details
Patch for all branches (792 bytes, patch)
2008-09-24 16:21 UTC, Jeremy Allison
no flags Details
samba log level 10 info from test of patch in comment #3 (348.21 KB, text/plain)
2008-09-26 18:57 UTC, Jeff Layton
no flags Details
Second part of the patch. (632 bytes, patch)
2008-09-26 20:34 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Layton 2008-09-24 07:29:46 UTC
I'm working on a patch for CIFS to fix deletion of busy files. This patch:

1) sets dos attrs on files using trans2 set_file_info
2) renames the file using trans2 rename by filehandle
3) sets delete on close bit using trans2 set_file_disposition call

On this last call, samba returns STATUS_OBJECT_NAME_NOT_FOUND, even though the filehandle is the same as the one used in the previous calls.

I've seen this against both RHEL5's samba:

samba-3.0.28-1.el5_2.1.x86_64

...and the one in Fedora Rawhide:

samba-3.2.1-0.19.fc10.x86_64

...I've worked around it for now by having the cifs code recognize an -ENOENT return from samba and ignore it.
Comment 1 Jeff Layton 2008-09-24 07:31:07 UTC
Created attachment 3622 [details]
log from samba during reproducer with log level set to 10
Comment 2 Jeff Layton 2008-09-24 07:32:09 UTC
Created attachment 3623 [details]
binary capture from same reproducer

...the part that I think is a bug is shown in frames 45 and 46
Comment 3 Jeremy Allison 2008-09-24 16:21:11 UTC
Created attachment 3627 [details]
Patch for all branches

This should fix it. We were checking for fd != -1 when we no longer need to (change in internal semantics).
Jeremy.
Comment 4 Jeff Layton 2008-09-26 18:55:40 UTC
Just built a 3.2.4 set of samba packages for my fedora rawhide box and tested the patch in comment #3. Some cifsFYI info:

 fs/cifs/cifssmb.c: Set File Disposition (via SetFileInfo)
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb:  total_len 79
 fs/cifs/connect.c: rfc1002 length 0x27
 fs/cifs/connect.c: invalid transact2 word count
Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND
 fs/cifs/netmisc.c: Mapping smb error code 2 to POSIX err -2
 fs/cifs/cifssmb.c: Send error in SetFileDisposition = -2
 fs/cifs/cifssmb.c: Rename to File by handle
 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb of length 104
 fs/cifs/connect.c: rfc1002 length 0x27
 fs/cifs/connect.c: invalid transact2 word count
Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND
 fs/cifs/netmisc.c: Mapping smb error code 2 to POSIX err -2
 fs/cifs/cifssmb.c: Send error in Rename (by file handle) = -2

...the other interesting thing is that subsequent calls against the same FH also return the same error (the messages above show that we get the same stuff when we try to rename the file back). So it may be that the initial rename is what triggers the problem.
Comment 5 Jeff Layton 2008-09-26 18:57:56 UTC
Created attachment 3640 [details]
samba log level 10 info from test of patch in comment #3
Comment 6 Jeff Layton 2008-09-26 19:55:23 UTC
Looking in the log, I see the rename take place and it seems to be successful. I then see this:

[2008/09/26 19:51:18,  3] smbd/trans2.c:call_trans2setfilepathinfo(6595)
  call_trans2setfilepathinfo: fileinfo of nfsxjZRsr failed (No such file or directory)
[2008/09/26 19:51:18,  3] smbd/error.c:reply_unix_error(154)
  unix_error_packet: error string = No such file or directory
[2008/09/26 19:51:18,  3] smbd/error.c:error_packet_set(61)
  error packet at smbd/trans2.c(6596) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_NAME_NOT_FOUND

...nfsxjZRsr is the original name of the file (before the rename). So from my naive reading of the code, it looks like maybe the fsp_name for this file isn't getting properly updated after the rename call.
Comment 7 Jeremy Allison 2008-09-26 20:03:40 UTC
It's ok, I've spotted the bug in the code. The patch is not quite complete. Working out the best way to fix this.
Thanks,
Jeremy.
Comment 8 Jeremy Allison 2008-09-26 20:34:04 UTC
Created attachment 3641 [details]
Second part of the patch.
Comment 9 Jeremy Allison 2008-09-26 20:34:50 UTC
Ok Jeff, layer this new patch on top of the other one (attachment #3 [details]) and this should fix it.
Jeremy.
Comment 10 Jeff Layton 2008-09-26 22:11:36 UTC
That seemed to fix it. Thanks!
Comment 11 Jeremy Allison 2008-09-26 23:32:37 UTC
Fixed in all branches.