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 improved. > > 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: /proc/sys/Device/HarddiskVolume2/Cygwin64/Cygwin.bat :) > 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. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
