This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FUSE for Cygwin - was: Re: Fork and Windows Heap

Hi Bill,

On Jun 17 07:25, Bill Zissimopoulos wrote:
> > How are you dealing with limitations of the Windows file system as seen
> > from a POSIX perspective? You say you can't support hard links.
> Windows hard links are rather un-POSIX like and rarely used on Windows.
> After considering the required changes on the FSD for a feature that is
> so rarely used I opted against supporting them.

I disagree here.  Windows hardlinks work fine and pretty much as on
POSIX with the exception of DOS mode bits.  Those are not per file but
per file entry as far as my experiecen goes.  One of the reasons we try
to ignore them as much as possible.

Hardlinks are pretty essential I think.  The API from user space is
rather simple as well (NtSetInformationFile ([...], FileLinkInformation)
and supported in Cygwin for the link(2) call practically since the last
century :)

> > How will a Cygwin program see symlinks exported by the FUSE file system?
> WinFsp will present symlinks as reparse points. Cygwin already knows how
> to deal with NTFS reparse points and it will present them as POSIX
> symlinks.
> I may even relax the whole âyou have to be admin to create a symlinkâ
> nonsense.

Full ACK!

> Please note that WinFsp does (not) yet support reparse points. There is no
> big obstacle in the way, just a question of time.
> > And pipes?
> Pipes in Windows are not stored in the file system, rather they are
> implemented by a special Windows file system called NPFS. OTOH POSIX
> FIFO's are special files. I am unsure at this time how Cygwin represents
> FIFO's.
> [Quick experiment:
> $ mkfifo foo; cmd /c dir 'foo*' | grep foo; rm foo
> 06/16/2016  11:02 PM               130 foo.lnk
> ]
> Ok, so they are shortcuts. Naturally they are supported.

...just the FIFO implementation itself... let's just say, it could be

> > You write that you are mapping
> >  - characters not supported by Win32 but by POSIX via the Unicode
> >    private use page
> >  - Security apspects (SID vs. uid/gid, ACL)
> > between POSIX and Windows and that you do it like Cygwin/SFU/SFM is
> > doing it.
> >
> > But if that's done by your code, a Cygwin process may see slightly
> > different mappings through WinFsp and through Cygwin. Won't that be a
> > potential for Bugs (misbehaving apps) or even for security issues?
> I agree that the potential is there. But I did not want WinFsp to depend
> on Cygwin so reimplementation was the best option for me. Additionally
> Cygwin does not expose this functionality to third party apps AFAIK.

Uhm... I don't understand.  Cygwin is using the private unicode range as
well to map characters invalid in a Windows filename (e.g. colon 0x3a is
mapped to 0xf03a).  This is how such filenames are given to the OS functions.

This means, WinFsp would get these filenames from a Cygwin process
already in the transposed form, with invalid FS chars transposed into the
private area.

If WinFsp would support that, it would be transparent to applications
with very minor effort.

> Try this from a cmd.exe prompt:
>     type \\?\GLOBALROOT\Device\HarddiskVolume2\Cygwin64\Cygwin.bat

Or thhis from Cygwin:



> For this reason alone, I expect that most user mode file systems
> will be packaged to work as network file systems.

That would make a lot of sense, I think.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]