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


On 6/18/16, 1:02 AM, "Corinna Vinschen" <cygwin-owner@cygwin.com on behalf
of corinna-cygwin@cygwin.com> wrote:


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

Unfortunately it is not as simple as that. A proper Rename implementation
needs to conform to rules that effectively require the FSD to maintain
filename/path information about open files.

From "FILE_RENAME_INFORMATION structureâ [1]:
<<
Special rules for renaming open files:

* A file cannot be renamed if it has any open handles, unless it is only
open because of a batch opportunistic lock (oplock) and the batch oplock
can be broken immediately.

* A file cannot be renamed if a file with the same name exists and has
open handles (except in the batch-oplock case described earlier).

* A directory cannot be renamed if it or any of its subdirectories
contains a file that has open handles (except in the batch-oplock case
described earlier).

>>

In particular the third bullet point mandates that the FSD keeps
information not only about files that are open, but also of their
hierarchical relationships. The easiest way to do this on Windows is to
maintain a mapping of file names to open files.

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

I have thought more about this.

As mentioned, originally the FSD maintained a mapping of IndexNumber to
âFileNodeâ somewhat similar to UNIX. This is because it is important for
an FSD to be able to identify when the same file is being reopened; for
example, to properly implement file deletion (a file gets deleted only
when its last handle is closed) or sharing or caching.

When I had to implement Rename, bullet point (3) above complicated
matters. So I ended up maintaining two tables for a while, one for
IndexNumbers and one for file names. Then I ended up scrapping the
IndexNumber table when I decided that I would not implement hard links
(for a variety of reasons).

Perhaps what I should have done instead is to maintain IndexNumber
relationships (parent/child) and do my rename tests based on that. Thatâs
what a VFS system would do, although I am not sure that it is the cleanest
solution within a Windows FSD.

Compounding this the user mode file system may not even send me back real
IndexNumberâs, so then I would have to fake them (e.g. file name hash).

In any case I am going to shelve this for a while and come back to it at a
later time as there are lots of higher priority (for me) things to do on
WinFsp.

--

In other news I made a new release yesterday and I am happy to say that
this release supports Cygwin. I am able to compile SSHFS with a minimal
patch and it runs correctly under Cygwin.

The SSHFS-Win repo is here [2].

I may actually go the extra mile and create a libfuse.dll so that things
like FUSEPY can work out of the box.

Bill

[1] 
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540344(v=vs.85)
.aspx
[2] https://bitbucket.org/billziss/sshfs-win


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