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/
