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 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.


> [...]
> 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 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]