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 (except in the batch-oplock case
>> described earlier).
>>
>>
>> In part
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
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 by index number. At least on NTFS.
Unfortunately it is not as s
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 opte
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 hardlin
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 r
[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 a
On 16.06.2016 08:37, Bill Zissimopoulos wrote:
I am not porting anything from UNIX. I have a Windows solution developed
using Visual Studio and the Windows Driver Kit that I am building a FUSE
compatibility layer for. My DLL is not a Cygwin DLL. It is a native
Windows DLL that also has a FUSE co
Hi, Corinna:
> You are correct. Cygwin fork only clones the datastructures explicitely
> set up by Cygwin and stuff allocated using Cygwin's POSIX API.
>
> You can't simply clone a Windows heap for various reasons...
Thank you for your detailed response and explanation.
Bill
Hi Bill,
On Jun 16 00:42, Bill Zissimopoulos wrote:
> I am the creator of WinFsp [1], a user mode file system solution for
> Windows (i.e. FUSE for Windows). WinFsp has its own API, but I have been
> working on adding a FUSE (high-level) API using SSHFS as my primary test
> case. This has proven t
Renà Berber wrote:
> On 6/15/2016 7:42 PM, Bill Zissimopoulos wrote:
> > (1) Is my assumption that Windows heaps are not properly cloned after a
> > fork correct? A 2011 post [2] seems to suggest so.
> > (2) Is there any workaround that the WinFsp DLL can use to get around
>this
> > limitation an
On 6/15/2016 7:42 PM, Bill Zissimopoulos wrote:
[snip]
> WinFsp consists of an FSD (file system driver) and a DLL component. The
> WinFsp DLL uses the Windows heap functions to manage memory
> (HeapAlloc/HeapFree). It seems that the Windows heap is not properly
> cloned after a fork, which leads t
I am the creator of WinFsp [1], a user mode file system solution for
Windows (i.e. FUSE for Windows). WinFsp has its own API, but I have been
working on adding a FUSE (high-level) API using SSHFS as my primary test
case. This has proven to work very well, except for one important problem
which is t
13 matches
Mail list logo
