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
signature.asc
Description: PGP signature
