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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

Hi Bill,

On Jun 17 19:48, Bill Zissimopoulos wrote:
> Hi, Corinna:
> 
> On Jun 17 07:25, Bill Zissimopoulos wrote:
> > > 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.
> 
> I no longer remember all the details now, because it was a few months ago
> that I looked into this and determined that hard links are "un-POSIX like".
> As far as I recall there was the FileAttributes issue (which I now think
> may have been my incorrect understanding of the documentation), but there
> was also the issue of FindFirstFileName/FindNextFileName, which is not
> something that POSIX supports out of the box (AFAIK).
> 
> Regarding the FileAttributes issue. The Windows documentation seems to
> suggest that they are stored with the file and not the directory entry.

Yes, you're right.  Apparently I didn't really think when writing.  The
*real* issue with DOS attributes is that they are per file :) That has
implications if you have multiple hardlinks to symlinks of the "Windows
shortcut" type, but that shouldn't affect your WinFSD.

> The bigger issue is that the FSD now maintains an internal table of open
> files that is indexed by file name. It actually started as a table of open
> files indexed by IndexNumber (inode number Windows equivalent),

Yeah, Cygwin is presenting them as i-node numbers.

> but I
> eventually had to change it for a number of issues (notably Rename
> support).

For rename support you can use the index number as well, usually,
since you can open a file by index number.  At least on NTFS.

> I am not saying that it would not be possible to change this
> part of WinFsp, I just believe that it is a non-trivial change at this
> moment.

Ok.

> [...]
> Let's examine the lifetime of a call to creat(). Suppose a Cygwin process
> does creat("/cygdrive/z/foo*bar"). In the following OP is the "originating
> process", CW is the "Cygwin runtime", NT is NTOS, WD is the "WinFsp FSD",
> WL is the "WinFsp DLL", FL is the "FUSE layer", and FS is the "user mode
> FUSE file system".
> 
> OP: creat("/cygdrive/z/foo*bar")
> CW: NtCreateFile(L"<DEVICE>\\foo\xf02abar")     <--- Cygwin translation
> NT: IRP_MJ_CREATE L"\\foo\xf02abar"
> WD: FspFsctlTransactCreateKind L"\\foo\xf02abar"
> WL: FSP_FILE_SYSTEM_INTERFACE::Create L"\\foo\xf02abar"
> FL: fuse_operations::create "/foo*bar"          <--- WinFsp/FUSE
> translation
> FS: somehow satisfies fuse_operations::create
> [snip return path]
> 
> The opposite happens when the file system communicates a file name back
> to the originating process, as in readdir().
> 
> OP: readdir("/cygdrive/z/")
> [snip call path]
> FS: fuse_operations::readdir response: "foo*bar"
> FL: FSP_FILE_SYSTEM_INTERFACE::ReadDirectory response: L"foo\xf02abar"
> WL: FspFsctlTransactQueryDirectoryKind response: L"foo\xf02abar"
> WD: IRP_MN_QUERY_DIRECTORY response: L"foo\xf02abar"
> NT: NtQueryDirectoryFile response: L"foo\xf02abar"
> CW: readdir response: "foo*bar"
> OP: receives "foo*bar"

If I'm not missing anything crucial, that's pretty much exactly what we
need.  The Cygwin process reads and writes the file as if the '*' is
a valid character and the entire process of mapping is completely
transparent to both sides.  Looks perfect to me.


Corinna

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

Attachment: signature.asc
Description: PGP signature