Bug 7410 - samba sends "raw" inode number as uniqueid with unix extensions
samba sends "raw" inode number as uniqueid with unix extensions
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.2
Other Linux
: P3 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-06 07:27 UTC by Jeff Layton
Modified: 2010-05-25 02:50 UTC (History)
2 users (show)

See Also:


Attachments
Patch for 3.5.x. (7.36 KB, patch)
2010-05-21 14:20 UTC, Jeremy Allison
jlayton: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Layton 2010-05-06 07:27:36 UTC
Samba sends a plain old inode number in the uniqueid field for QUERY_PATH_INFO with the unix extensions infolevel. This causes problems for the Linux CIFS client which currently expects that the uniqueid is well...unique!

This needs to be fixed. There are related bugs in the Linux CIFS client that I'll be working on here:

https://bugzilla.samba.org/show_bug.cgi?id=7407

...but this also needs to be fixed in samba too.

The problem is that we don't have enough bits to guarantee uniqueness. We need to store info about the st_ino and st_dev from the stat() system call, but we only have 64 bits.

Jeremy mentioned in passing that he could fix this if we don't need consistency in these numbers across sessions. I'll suggest that we should take this to dochelp or someone at MS to see whether this is the case with windows. If it's not the case there, then we'll have to deal with it anyway so we might as well be ok with that. If windows however has consistent uniqueid's across reconnects then I think samba should strive for the same. It would be much simpler for the Linux CIFS client if they were consistent.
Comment 1 Jeremy Allison 2010-05-20 13:43:14 UTC
Jeff - should be fixed in master (for 3.6.0) with commit a8a4fe0605e6149efb5f9051181d794572edbf27. Please review and comment.

Jeremy.
Comment 2 Jeff Layton 2010-05-20 13:56:28 UTC
Looks like a reasonable way to handle this (nice work). I suppose it's still possible to get collisions, but this should hopefully make them unlikely.

One thing we haven't considered is incorporating something like the i_generation field to give some semblance of uniqueness across inode delete/create operations and inode number reuse.

Maybe if/when Aneesh's name-to-filehandle patches come into fruition we can consider using those new syscalls to get uniqueid's...
Comment 3 Jeremy Allison 2010-05-21 14:20:00 UTC
Created attachment 5730 [details]
Patch for 3.5.x.

Jeff, please review and then re-assign to Karolin for inclusion in 3.5.x.
Jeremy.
Comment 4 Jeff Layton 2010-05-22 09:02:45 UTC
Comment on attachment 5730 [details]
Patch for 3.5.x.

Looks good to me, though my familiarity with the code in samba is not as good as some others'.
Comment 5 Jeff Layton 2010-05-22 09:03:43 UTC
Reassigning to Karolin for inclusion in 3.5.x
Comment 6 Karolin Seeger 2010-05-25 02:50:35 UTC
Pushed to v3-5-test.
Closing out bug report.

Thanks!