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/
