This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Cygwin and Interix interoperability?
On Apr 20 16:42, mwoehlke wrote:
> Corinna Vinschen wrote:
> >We're already having two different symlink types, one of them U/Win
> >compatible. I'm, too, not really interested in adding another one(*),
> >especially when there's no documentation and, TTBOMK, no Win32 API.
>
> True; it might require linking against Interix (yuck), which is only
> feasible with SUA 5.2. There is nevertheless a very real chance that I
I don't think that's feasible for Cygwin, though. Interix is not just a
Win32 DLL as Cygwin, it's an entirely different subsystem. I don't even
want to know the implications when trying to link against the Interix
subsystem.
> will look into this, as this would be really useful for me, as most of
> the files I work with exist on NFS.
>
> Even better, believe it or not, the Windows subsystem actually
> understands them! Which actually means that they are currently invisible
> to Cygwin. If Cygwin could make these, then they would be understood
> *transparently* by the rest of Windows (on NFS volumes, anyway)!
They are not understood by Windows, and that's documented. They are
just translated into the file type they are pointing to by the NFS
client and then presented as file or directory to Windows clients. No
Windows client knows that they are symlinks, which makes sense since
Windows clients have no idea what a symlink is.
> >Same for the SFU NFS permission handling which doesn't seem to work
> >transparently using the Win32 security API.
>
> I would assume that there is a different interface for NFS permissions,
> as they show up in Explorer on an 'NFS Attributes' tab (which, however,
> means that at some level they are accessible to normal Windows
> applications; even SFU ones where mixed-mode is not supported). It a
> different way, IMO this is /more/ worth looking into because one could
> argue that you're "reducing" complexity rather than adding it.
On the contrary. All the Windows calls are naturally using the Win32
security datatypes and so, even if there's an API, the POSIX permissions
would have to be translated to Windows ACLs to make sense in Win32 calls.
Otherwise you would have to augment every file system related call with
special NFS considerations. That's just plain ugly.
I made a quick test. If you retrieve the security descriptor from a
file or directory on an NFS share, you get the following information,
all the time, regarless of the real owner, real group, and real permissions:
Owner: S-1-1-0 == "Everyone"
Group: S-1-1-0 == "Everyone"
DACL: NULL == Full access for everyone.
And that happens even though the user/group name mapping of the NFS
client is in place and configured, and the Unix names on the share
should be mapped to existing Windows users.
Eventually, the only one who could change this, is Microsoft.
I don't ask for opening up the NFS sources, and I don't even ask for a
Win32 API. What I really ask for is that the integration of the NFS
client is improved. Windows clients should be able to use the security
API on files and directories on NFS shares. The user/group name mapping
should work transparently, so that, say, a call to GetFileSecurity
returns a security descriptor with correct owner and group SIDs and with
a usefully constructed DACL. Analoguos for setting the file security.
And GetVolumeInformation should return a couple of more flags set to
true, especially FILE_PERSISTANT_ACLS. It's really sad that NFS shares
are not better than FAT file systems from the perspective of Win32
applications.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/