When mounting a samba share from a win2k box with interix sfu installed, the inode numbers that samba reports are not shown correctly within the sfu shell. On Linux: stat testfile File: `/misc/tmp/testfile' Size: 182 Blocks: 8 IO Block: 4096 regular file Device: 816h/2070d Inode: 4161736 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1001/ martin) Gid: ( 1001/ martin) Access: 2005-11-22 19:17:12.000000000 +0100 Modify: 2005-11-18 21:56:09.000000000 +0100 Change: 2005-11-28 00:19:40.000000000 +0100 On Windows/sfu: ls -lin testfile 2070 -rw-rw-r-- 1 3002 3003 182 Nov 18 21:56 testfile So within interix/sfu the device number is shown instead of the inode number. To verify this I have written the following small program which shows the result of GetFileInformationByHandle(). #define WIN32_LEAN_AND_MEAN #include <stdio.h> #include <tchar.h> #include <windows.h> void printerror() { DWORD msgid = GetLastError(); _TCHAR msg[1024]; FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, msgid, 0, msg, sizeof(msg), NULL); _tprintf(_T("Could not open file (error %d): %s\n"), msgid, msg); } int _tmain(int argc, _TCHAR* argv[]) { _tprintf(_T(" ino_h ino_l link file\n")); for (int i = 1; i < argc; i++) { HANDLE fh = CreateFile( argv[i], GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); if (fh == INVALID_HANDLE_VALUE) { printerror(); continue; } BY_HANDLE_FILE_INFORMATION fi; memset(&fi, 0, sizeof(fi)); BOOL res = GetFileInformationByHandle(fh, &fi); if (!res) { printerror(); continue; } _tprintf(_T("%10d %10d %4d %s\n"), fi.nFileIndexHigh, fi.nFileIndexLow, fi.nNumberOfLinks, argv[i]); CloseHandle(fh); } return 0; } The output shows the following: ino_h ino_l link file 4161736 2070 1 T:\testfile So samba reports the inode number, but in nFileIndexHigh, not in nFileIndexLow. I think these 2 fields should be swapped, i.e. low=inode, high=device.
Jeremy, I'm leaving this on for you.
I just tested with 3.0.21rc1, but same behaviour.
On Mac OS X 10.4.3 with included samba 3.0.10 the same ugly values are returned: FileIndexLow = device number and FileIndexHigh = inode number. So this doesn't seem to be Linux specific, nor to be an endianness issue. Thanks to Peter Rehley for testing this. On Windows: =========== z:\tmp\GetFileInfo.c: FileAttributes: 80 VolumeSerialNo: 1319704160 NumberOfLinks : 1 FileIndexHigh : 97918d FileIndexLow : e000002 z:\tmp\GetVolInfo.c: FileAttributes: 80 VolumeSerialNo: 1319704160 NumberOfLinks : 1 FileIndexHigh : 97918c FileIndexLow : e000002 z:\tmp\inode_test: FileAttributes: 10 VolumeSerialNo: 1319704160 NumberOfLinks : 14 FileIndexHigh : 978f11 FileIndexLow : e000002 z:\tmp\inode_test\t1: FileAttributes: 10 VolumeSerialNo: 1319704160 NumberOfLinks : 2 FileIndexHigh : 978f13 FileIndexLow : e000002 z:\tmp\inode_test\t2: FileAttributes: 10 VolumeSerialNo: 1319704160 NumberOfLinks : 2 FileIndexHigh : 978f14 FileIndexLow : e000002 z:\tmp\inode_test\t3: FileAttributes: 10 VolumeSerialNo: 1319704160 NumberOfLinks : 2 FileIndexHigh : 978f15 FileIndexLow : e000002 "stat" on Mac OS X: =================== 234881026 9933197 -rw-r--r-- 1 [...] 4096 8 0 GetFileInfo.c 234881026 9933196 -rw-r--r-- 1 [...] 4096 8 0 GetVolInfo.c 234881026 9933336 -rw-r--r-- 1 [...] 4096 8 0 getinfo.out 234881026 9932561 drwxr-xr-x 14 [...] 4096 0 0 inode_test 234881026 9932563 drwxr-xr-x 2 [...] 4096 0 0 inode_test/t1 234881026 9932564 drwxr-xr-x 2 [...] 4096 0 0 inode_test/t2 234881026 9932565 drwxr-xr-x 2 [...] 4096 0 0 inode_test/t3
I had a deeper look into this, and found the cause in smbd/trans2.c An untested, but rather trivial patch is attached.
Created attachment 1614 [details] patch for smbd/trans2.c
Applied - thanks ! Jeremy.
Created attachment 1622 [details] patch for the patch Jeremy, I should have tested even that simple patch... Here comes a now tested patch for my patch, i.e. to be applied to the already patched version. The only good think is that bug #3295 now turns out to be a duplicate of this one. Sorry Martin
My first patch is unfortunately not completely correct.
*** Bug 3295 has been marked as a duplicate of this bug. ***
Applied, thanks. Jeremy.