X-Spam-Check-By: sourceware.org
Date: Mon, 28 Nov 2005 16:36:43 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: faked inode numbers on network drives
Message-ID: <20051128153643.GJ2999@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <Pine DOT LNX DOT 4 DOT 62 DOT 0511261420410 DOT 3810 AT vmdebian DOT local DOT koeppe-net DOT de> <20051127140448 DOT GU2999 AT calimero DOT vinschen DOT de> <Pine DOT LNX DOT 4 DOT 62 DOT 0511281547220 DOT 3414 AT vmdebian DOT local DOT koeppe-net DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.62.0511281547220.3414@vmdebian.local.koeppe-net.de>
User-Agent: Mutt/1.4.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Nov 28 15:53, Martin Koeppe wrote:
> 
> On Sun, 27 Nov 2005, Corinna Vinschen wrote:
> 
> >>And I ask why such an assumption is necessary at all.
> >>In the Windows API there is a function GetVolumeInformation
> >>which is supported from Win95 on and reports FILE_SUPPORTS_OBJECT_IDS
> >>when inode numbers are valid.
> >
> >Nope.  Object IDs are not inode numbers.  I suggest reading on object
> >IDs in MSDN.
> 
> Thanks, and sorry for not being thorough enough before writing the 
> mail.
> 
> >>Is there a reason for not using this? GetVolumeInformation is already
> >>used in several other places within cygwin.
> >
> >Samba reports FS_PERSISTENT_ACLS, but the way has_acls() is treated
> >in case of CYGWIN=nosmbntsec (the default) disables its usage.  I think
> >I found a bug though, which might explain inconsistent behaviour.  I'm
> >looking into it.
> >
> >But using FILE_SUPPORTS_OBJECT_IDS is definitely incorrect.  And, just
> >as a side note, the Samba version I'm using (3.0.20a) does not report
> >that it supports FILE_SUPPORTS_OBJECT_IDS.  The flags value returned
> >from GetVolumeInformation:
> >
> > 11 == 0xb == FILE_CASE_SENSITIVE_SEARCH
> >              | FILE_CASE_PRESERVED_NAMES
> >              | FILE_PERSISTENT_ACLS
> 
> Ok. I now wrote and executed a small program which shows the inode 
> numbers returned by GetFileInformationByHandle() to see which inode 
> numbers are definitely non-sense and which could be real ones.
> (Because of GetVolumePathName() used for brevity, this program only 
> runs on >=W2K.)
> 
> On a W2K box, I tested several file systems, local and remote.
> Here are the results:
> 
>      ino_h       ino_l  link    fsname  file
>    2883584       82115     1      NTFS  C:\local_harddisk\testfile
>    4161736        2070     2      NTFS  T:\samba3_share\testfile
>    6881280       20695     1      NTFS  P:\w2k3_share\testfile
>          0  -465645560     1     FAT32  W:\win98_share\testfile1
>          0  -467871288     1     FAT32  W:\win98_share\testfile2
>          0         568     1      CDFS  E:\local_cdrom\testfile1
>          0         516     1      CDFS  E:\local_cdrom\testfile2
>          0      258336     1       FAT  G:\local_usbstick\testfile1
>          0      254880     1       FAT  G:\local_usbstick\testfile2
> 
> (samba reports the device number as low part of the inode number, and 
> the real ext2 fs inode number as high part, which is bad for 
> interix/sfu, as it only shows the low part as inode number. I just 
> reported this as samba bug 3287, see 
> https://bugzilla.samba.org/show_bug.cgi?id=3287 )
> 
> For the Win98 share, one gets random numbers on each call. The other 
> numbers are constant, at least between reboots. (I didn't yet test 
> after reboot.)

Yes, that matches our observations.  I've applied a fix already.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/