Bug 3287 - samba reports inode numbers incompatible to interix sfu
samba reports inode numbers incompatible to interix sfu
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.14a
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
: 3295 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-28 06:07 UTC by Martin Koeppe
Modified: 2006-01-25 23:55 UTC (History)
1 user (show)

See Also:


Attachments
patch for smbd/trans2.c (1.17 KB, patch)
2005-12-12 16:21 UTC, Martin Koeppe
no flags Details
patch for the patch (484 bytes, patch)
2005-12-18 14:15 UTC, Martin Koeppe
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Koeppe 2005-11-28 06:07:10 UTC
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.
Comment 1 Gerald (Jerry) Carter 2005-11-28 08:59:04 UTC
Jeremy, I'm leaving this on for you.
Comment 2 Martin Koeppe 2005-12-01 03:58:52 UTC
I just tested with 3.0.21rc1, but same behaviour.
Comment 3 Martin Koeppe 2005-12-06 14:12:36 UTC
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
Comment 4 Martin Koeppe 2005-12-12 16:18:35 UTC
I had a deeper look into this, and found the cause in smbd/trans2.c
An untested, but rather trivial patch is attached.
Comment 5 Martin Koeppe 2005-12-12 16:21:30 UTC
Created attachment 1614 [details]
patch for smbd/trans2.c
Comment 6 Jeremy Allison 2005-12-14 16:52:29 UTC
Applied - thanks !
Jeremy.
Comment 7 Jeremy Allison 2005-12-14 16:52:46 UTC
Applied - thanks !
Jeremy.
Comment 8 Martin Koeppe 2005-12-18 14:15:34 UTC
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
Comment 9 Martin Koeppe 2005-12-18 14:18:06 UTC
My first patch is unfortunately not completely correct.
Comment 10 Martin Koeppe 2005-12-18 14:18:39 UTC
*** Bug 3295 has been marked as a duplicate of this bug. ***
Comment 11 Jeremy Allison 2005-12-19 16:06:22 UTC
Applied, thanks.
Jeremy.