faked inode numbers on network drives

[Corinna Vinschen]

On Nov 26 14:49, Martin Koeppe wrote:
> There is the following assumption:
>  /* Assume that if a drive has ACL support it MAY have valid "inodes".
>      It definitely does not have valid inodes if it does not have ACL
>      support. */
> 
> I think this assumption is wrong. Imagine a samba share without acl 
> support. It nevertheless has valid inode numbers.
> 
> Furthermore, in the following switch() statement, inode numbers on 
> network drives are always ignored.
> 
> 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.

> 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


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/