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:
...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.
Jeff - should be fixed in master (for 3.6.0) with commit a8a4fe0605e6149efb5f9051181d794572edbf27. Please review and comment.
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...
Created attachment 5730 [details]
Patch for 3.5.x.
Jeff, please review and then re-assign to Karolin for inclusion in 3.5.x.
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'.
Reassigning to Karolin for inclusion in 3.5.x
Pushed to v3-5-test.
Closing out bug report.