This is the mail archive of the
mailing list for the Cygwin project.
Re: faked inode numbers on network drives
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Cc: Martin Koeppe <mkoeppe at gmx dot de>
- Date: Sun, 27 Nov 2005 15:04:48 +0100
- Subject: Re: faked inode numbers on network drives
- References: <Pine.LNX.firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
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
11 == 0xb == FILE_CASE_SENSITIVE_SEARCH
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