would be to
have the DLL use Cygwin's malloc/free and this is indeed possible within
the DLL's FUSE layer, but not workable elsewhere.
Any insights welcome.
Bill Zissimopoulos
[1] http://www.secfs.net/winfsp/
[2] https://www.cygwin.com/ml/cygwin-developers/2011-04/msg00035.html
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
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
[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:
>
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
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 wh
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
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
>> de
Hi, Herbert:
On 6/19/16, 4:20 AM, "cygwin-ow...@cygwin.com on behalf of Herbert
Stocker" 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)...
>
>To repeat your 3 modes of operation (in my words):...
>
>(3) The fil
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 Posix to Win32 and then back (which is done again
>for
TLDR: I am trying to use delay loading with Cygwin. Is it supported?
I have found information that I can do something along the following lines:
gendef NATIVE.dll
dlltool --input-def NATIVE.def --output-delaylib NATIVE.dll.a
gcc -shared -o cygNAME.dll -Wl,--out-implib=libN
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 are marked as case-sensitive by default.
>
>If WinFsp
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), but there is a
>>large
>
EXEUTIVE EDITION
I am seeking information on how exactly Cygwin uses NULL SID ACE’s in
Windows ACL’s. Cygwin’s use of NULL SID ACE’s interferes with my use of
the NULL SID to represent “nobody”/“nogroup”.
AN EXPERIMENT
Working through some remaining warts in my WinFsp-FUSE for Cygwin layer I
st
On 6/24/16, 12:51 PM, "Corinna Vinschen" wrote:
>>Could my mapping of the NULL SID somehow interfere with Cygwin’s ACL
>> mapping? No way right? Turns out that: yes!
>>File:winsup/cygwin/sec_acl.cc,
>> line:787
>
>Read the comment at the beginning of the file explaining how new-style
>ACLs look
On 6/24/16, 2:59 PM, "Corinna Vinschen" wrote:
>>>If you want some specific mapping we can arrange that, but it must not
>> >be the NULL SID. If you know you're communicating with a Cygwin
>>process,
>> >what about using an arbitrary, unused SID like S-1-0-42?
>>
>> I am inclined to try S-1-5-
On 6/24/16, 3:06 PM, "cygwin-ow...@cygwin.com on behalf of Erik
Soderquist" wrote:
>On Fri, Jun 24, 2016 at 5:59 PM, Corinna Vinschen wrote:
>>> I am inclined to try S-1-5-7 (Anonymous). But I do not know if that is
>>>a
>>> bad choice for some reason or other.
>>
>> I thought about Anonymous my
On 6/24/16, 3:53 PM, "cygwin-ow...@cygwin.com on behalf of Bill
Zissimopoulos" wrote:
>One caveat is that Cygwin already maps S-1-5-7 to uid 7. So does that mean
>that 7==nobody in Cygwin’s case?
Here is output from Cygwin/SSHFS after mapping “nobody/nogroup” to S-1-5-7:
<
On 6/24/16, 2:59 PM, "Corinna Vinschen" wrote:
>>>If you want some specific mapping we can arrange that, but it must not
>> >be the NULL SID. If you know you're communicating with a Cygwin
>>process,
>> >what about using an arbitrary, unused SID like S-1-0-42?
>>
>> I am inclined to try S-1-5-
>Why don't we just follow Fedora Linux here and use a mapping to either
>99 (nobody) or 65534 (nfsnobody)? Both uid values are ununsed in the
>mapping and 65534 aka 0xfffe has the additional advantage that it's not
>mapped at all (all values between 0x1000 and 0x are invalid).
>
>Also, since
On 6/28/16, 3:27 AM, "Corinna Vinschen" wrote:
>>Ok. Please keep in mind that
>
>a) there can't be a bijective mapping between arbitrary length SIDs
> and a 32 bit uid/gid.
>
>b) The mapping used in Cygwin is not self-created but (mostly, except
> for a single deviation) identical to the In
On 6/29/16, 1:21 AM, "Corinna Vinschen" wrote:
>If that's the case, then why do you explain all these things to me? I'm
>a bit at a loss to see the difference between me explaining things to
>you you already know vs. you explaing things to me I already know.
>Aren't we kind of on par here?
Yes
While on vacation I have been (slowly) working to add reparse point and
symbolic link support for WinFsp and FUSE for Cygwin. This work is mostly
complete and is currently being tested.
I am writing to the Cygwin list because I want to resolve a problem that
Herbert Stocker originally brought up:
On 8/25/16, 7:14 PM, Jeffrey Altman wrote:
>On 8/25/2016 11:21 AM, Corinna Vinschen wrote:
>>Granted, it *could* be used by Cygwin on NTFS to indicate Cygwin's own
>> implementations of AF_LOCAL sockets or fifos. Or even for symlinks.
>> But that would only introduce YA symlink type which would b
On 8/25/16, 5:46 PM, Jeffrey Altman wrote:
>The only file system for which this tag is known to be interpreted is
>the Microsoft NFS provider that will report its
>
> FILE_REMOTE_PROTOCOL_INFORMATION.Protocol
>
>value as
>
> #define WNNC_NET_MS_NFS 0x0042
I missed this. Jeffrey do
On 8/25/16, 3:45 PM, Corinna Vinschen wrote:
>On Aug 25 11:46, Bill Zissimopoulos wrote:
>>In the following OP is the originating process, CW is the Cygwin
>> layer, WL is the WinFsp layer and FL is the FUSE layer.
>>
>> OP: mkfifo("myfifo")
>&
On 8/26/16, 11:05 AM, Corinna Vinschen wrote:
>On Aug 25 19:04, Bill Zissimopoulos wrote:
>>- The first case is during the processing of NtCreateFile (without the
>> FILE_OPEN_REPARSE_POINT flag set).
>
>This case doesn't matter to us. Cygwin always opens the file wit
On 8/26/16, 4:59 PM, cygwin-ow...@cygwin.com Bill Zissimopoulos wrote:
>On 8/26/16, 11:05 AM, Corinna Vinschen wrote:
>
>>On Aug 25 19:04, Bill Zissimopoulos wrote:
>>>- The first case is during the processing of NtCreateFile (without the
>>> FILE_OPEN_REPARSE_P
Do the packages id3tag and lame exist for Cygwin? I would like to try
compiling mp3fs on Cygwin and I cannot find them.
Bill
On 9/22/16, 12:37 PM, Yaakov Selkowitz wrote:
>On 2016-09-22 14:12, Bill Zissimopoulos wrote:
>> Do the packages id3tag and lame exist for Cygwin? I would like to try
>> compiling mp3fs on Cygwin and I cannot find them.
>
>If you mean libid3tag, it is available in the
On 9/22/16, 12:37 PM, Yaakov Selkowitz wrote:
>lame cannot be shipped however
>for legal reasons, but it's easy to build yourself with cygport:
>
>https://github.com/cygwinports-extras/lame
Alas this fails:
$ cygport lame.cygport compile
>>> Compiling lame-3.99.5-2.x86_64
autoreconf-2.69: Enteri
On 9/22/16, 2:06 PM, Yaakov Selkowitz wrote:
>On 2016-09-22 15:55, Bill Zissimopoulos wrote:
>> On 9/22/16, 12:37 PM, Yaakov Selkowitz wrote:
>>> lame cannot be shipped however
>>> for legal reasons, but it's easy to build yourself with cygport:
>>>
>&
On 9/23/16, 12:40 AM, Csaba Raduly wrote:
>On Thu, Sep 22, 2016 at 11:58 PM, Bill Zissimopoulos wrote:
>>
>> BTW, you mentioned a legal problem. I am seeing that LAME is LGPL
>>licensed
>> and therefore should be eligible for inclusion in Cygwin(?).
>
On 9/22/16, 3:35 PM, David Stacey wrote:
>On 22/09/16 22:58, Bill Zissimopoulos wrote:
>> BTW, you mentioned a legal problem. I am seeing that LAME is LGPL
>>licensed
>> and therefore should be eligible for inclusion in Cygwin(?).
>
>No, there are plenty of LGPL pack
Does Cygwin have any support for BSD file flags (UF_* flags, such as
UF_HIDDEN, etc.)? These flags are often used to provide support for
Windows file attributes (FILE_ATTRIBUTE_*, such as FILE_ATTRIBUTE_HIDDEN).
OSX and FreeBSD provide such support during stat(2) and chflags(2). I
expect that Cygw
had to deal with stat(2) changes over the years,
but I am not as familiar with Cygwin history.]
Bill
On 11/14/17, 2:06 AM, Corinna Vinschen wrote:
>On Nov 13 23:21, Bill Zissimopoulos wrote:
>> Does Cygwin have any support for BSD file flags (UF_* flags, such as
>> UF_HIDDEN, etc
36 matches
Mail list logo
