Re: FUSE for Cygwin

On 6/22/16, 1:39 PM, "Jeffrey Altman" wrote: >On 6/22/2016 3:43 PM, Bill Zissimopoulos wrote: >> >> The bigger question is whether the Cygwin community would want a package >> like this. The obvious answer might be yes (I hope),

Re: FUSE for Cygwin

On 6/22/2016 3:43 PM, Bill Zissimopoulos wrote: > > The bigger question is whether the Cygwin community would want a package > like this. The obvious answer might be yes (I hope), but there is a large > caveat. WinFsp includes a kernel-mode driver that needs to be built using > Microsoft tools and

Re: FUSE for Cygwin

Hi, Herbert: On 6/19/16, 1:32 PM, "cygwin-ow...@cygwin.com on behalf of Herbert Stocker" wrote: >>>G) Case sensitivity. >> >> WinFsp (and Windows) allows for both case-sensitive and case-insensitive >> file systems. > > >> FUSE file systems

Re: FUSE for Cygwin

Hi Bill, i agree with you that there are only two context switches involved and that Cygwin processes are not 2nd class performance. But i was *not* talking about context switches. i was talking about *translating of semantics* mostly in my mail. Because i was trying to avoid translation from

Re: FUSE for Cygwin

On 6/19/16, 4:20 AM, "cygwin-ow...@cygwin.com on behalf of Herbert Stocker" wrote: >What i don't like on (3) is that when a Cygwin process accesses the >FUSE file system there are two Cygwin processes whose communication >is translated from

Re: FUSE for Cygwin

Hi, Herbert: On 6/19/16, 4:20 AM, "cygwin-ow...@cygwin.com on behalf of Herbert Stocker" <cygwin-ow...@cygwin.com on behalf of her...@gmx.de> wrote: >this is now my proposal of an alternative mode for WinFsp to support >Cygwin based FUSE file systems. I'll call it mode (4

Re: FUSE for Cygwin

Hi Bill, this is now my proposal of an alternative mode for WinFsp to support Cygwin based FUSE file systems. I'll call it mode (4). It's actually my initial idea that i have in mind for some time but did not propose to implement because i have some constraints that prevent me from completing

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

Hello, Jeffrey: On 6/18/16, 1:19 PM, "Jeffrey Altman" wrote: >On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote: >> * A directory cannot be renamed if it or any of its subdirectories >> contains a file that has open handles

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

On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote: > * 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

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

On 6/18/16, 1:02 AM, "Corinna Vinschen" 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

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

Re: FUSE for Cygwin

Hi, Herbert: > > WinFsp provides three (3) different modes of integration: [snip] > i'm planning to make a suggestion of mode (4). It will be in addition or > instead of (3) and will avoid those issues we touched. I think (based on your earlier ask re: bindings to Python, Perl, etc.) I may see

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

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

Re: FUSE for Cygwin

On 6/17/2016 9:25 AM, Bill Zissimopoulos wrote: WinFsp provides three (3) different modes of integration: (1) Its own native API, which allows a user mode file system to do almost anything NTFS can do (with a few exceptions). It also allows for the Read, Write and ReadDirectory callbacks to be

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

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

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

[I apologize if my responses to the list appear to break the mailing list's threading model. I am not actually subscribed to the list and I respond to individual messages using my mail app.] Hello, Herbert: Herbert Stocker wrote: > > On 16.06.2016 08:37, Bill Zissimopoulos wrote: > > > > I have

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

work, with its undocumented and grown API. You should write a book documenting all the knowledge you gathered through your research, if the only one available is from '97 as you say. Really, great work. Also that you add the FUSE API. Having FUSE available for Cygwin and maybe for Windows apps