Re: BSD file flags support in Cygwin?

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

BSD file flags support in Cygwin?

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

Re: Id3tag and lame packages?

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

Re: Id3tag and lame packages?

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(?). >

Re: Id3tag and lame packages?

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: >>> >>&g

Re: Id3tag and lame packages?

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:

Re: Id3tag and lame packages?

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

Id3tag and lame packages?

Do the packages id3tag and lame exist for Cygwin? I would like to try compiling mp3fs on Cygwin and I cannot find them. Bill

Re: cygfuse

On 9/20/16, 10:33 PM, Mark Geisert wrote: >On Tue, 20 Sep 2016, Bill Zissimopoulos wrote: >> Mark, has there been any additional progress on this? > >No activity. I was not expecting Dokany to be fully integrated before >ITPing cygfuse, but I had hoped to hear at least that

Re: cygfuse (was Re: [ITP] FUSE 2.8)

On 9/8/16, 1:03 AM, Mark Geisert wrote: >I've changed Subject: to reflect what's being discussed now. When we >have a >consensus cygfuse I'll issue an ITP for it. > >I've now updated the cygfuse repository on GitHub so it is more neutral >about >FUSE implementations. It can be seen at

Re: FUSE, symbolic links and special files

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

Re: [ITP] FUSE 2.8

On 9/8/16, 5:01 AM, Corinna Vinschen wrote: >On Sep 6 21:13, Bill Zissimopoulos wrote: >> On 9/5/16, 2:35 AM, Mark Geisert wrote: >>>I wasn't sure from Corinna's comments a while back (re hosting this >> >package) >> >whether she thought cygfuse sh

Re: [ITP] FUSE 2.8

On 9/5/16, 1:16 PM, Mark Geisert wrote: >Adrien JUND wrote: >>> Separate from that, it's been a little work disentangling the meaning >>>of various names used for this project. Here's what I think the names >>>mean: >>> >>> FUSE - a protocol, which exists in different versions >>> WinFSP - a

Re: [ITP] FUSE 2.8

On 9/5/16, 2:35 AM, Mark Geisert wrote: >>While still on vacation I now have reliable access to the Internet and am >> able to follow up on any issues. Please let me know what the issue you >>are >> seeing is and I will try to help. Mark, I am now back from vacation and should be able to follow

Re: FUSE, symbolic links and special files

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

Re: FUSE, symbolic links and special files

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") >&

Re: FUSE, symbolic links and special files

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

Re: FUSE, symbolic links and special files

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

FUSE, symbolic links and special files

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:

Re: [ITP] FUSE 2.8

On 8/22/16, 12:43 PM, cygwin-apps-ow...@cygwin.com on behalf of Mark Geisert wrote: >>>I was planning to make sure the package Bill supplied met all the >>> requirements for a Cygwin package. I figure it's real close but there >>>was >>> something I wasn't sure about and needed to research

Re: [ITP] FUSE 2.8

Mark, hi: On 8/22/16, 12:43 PM, cygwin-apps-ow...@cygwin.com on behalf of Mark Geisert wrote: >>>I was planning to make sure the package Bill supplied met all the >>> requirements for a Cygwin package. I figure it's real close but there >>>was >>> something I wasn't sure about and needed to

Re: [ITP] FUSE 2.8

On 7/29/16, 1:19 AM, Mark Geisert wrote: >FWIW I've signed up with GitHub with username mgeisert. I think I need >to be >invited to join the cygwin@github org. Then maybe I can transfer your >repo to >me? Corrections welcome... Hey, Mark. I just transferred the cygfuse repo under your

Re: [ITP] FUSE 2.8

Hi, Mark: On 7/28/16, 10:29 AM, Mark Geisert wrote: Please be mindful if you intend to test that the current released binary of WinFsp does not support Windows 7. This is because the last release erroneously uses a Windows 8 only API (GetOverlappedResultEx). >>> >>> It's your

Re: [ITP] FUSE 2.8

On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: >On 7/28/16, 5:04 PM, Mark Geisert wrote: > >>Bill Zissimopoulos wrote: >>> On 7/28/16, 1:04 PM, Corinna Vinschen wrote: >>> >>>>github Cygwin org? >>>> >>>> https://g

Re: [ITP] FUSE 2.8

On 7/28/16, 5:04 PM, Mark Geisert wrote: >Bill Zissimopoulos wrote: >> On 7/28/16, 1:04 PM, Corinna Vinschen wrote: >> >>>github Cygwin org? >>> >>> https://github.com/cygwin >>> >>> Every Cygwin-related project is welcome. >>

Re: [ITP] FUSE 2.8

On 7/28/16, 1:04 PM, Corinna Vinschen wrote: >On Jul 28 19:13, Bill Zissimopoulos wrote: >> Mark: >> >> >I agree with how you want to adjust license and transfer ownership. I >> >don't >> >have a presence on GitHub but I should be able to grab

Re: [ITP] FUSE 2.8

>Mark, if at some point you do get a github account, I will be happy to >transfer ownership of the project as well. To clarify, I meant: “I will be happy to transfer ownership of the github repository as well”. Bill

Re: [ITP] FUSE 2.8

ou do get a github account, I will be happy to transfer ownership of the project as well. In the mean time do you have somewhere where you intend to host it? Regards, Bill Zissimopoulos [CYGFUSE]: https://github.com/billziss-gh/cygfuse

Re: [ITP] FUSE 2.8

On 7/28/16, 10:29 AM, Mark Geisert wrote: >>I am going to really try to get that Win 7 supporting build out by the >>end >> of Thursday (Pacific time). > >That's the timezone I'm in. I'll see what's going on later tonight :) . Ok, great. Then we should be able to do this today. >My mistake.

Re: [ITP] FUSE 2.8

On 7/28/16, Mark Geisert wrote: >Bill Zissimopoulos wrote: >> Please be mindful if you intend to test that the current released binary >> of WinFsp does not support Windows 7. This is because the last release >> erroneously uses a Windows 8 only API (GetOverlappedResultE

Re: [ITP] FUSE 2.8

On 7/27/16, 2:03 AM, Mark Geisert wrote: >Bill Zissimopoulos writes: >> To test that things work, clone my sshfs repo from: >> >> https://github.com/billziss-gh/sshfs >> >> And issue the following commands: >> >> $ autoreconf -i >&g

Re: [ITP] FUSE 2.8

On 7/26/16, 12:02 PM, Mark Geisert wrote: >If this turns out to be a workable solution, I am willing to be maintainer >of the glue library Bill is offering. I have created a new repository here: https://github.com/billziss-gh/cygfuse It contains the following: - fuse.cygport - cygfuse.c

Re: [ITP] FUSE 2.8

On 7/26/16, 1:07 PM, Adrien JUND wrote: >Excellent idea Bill ! >I am absolutely willing to do it ! > >Dokan install folder can also be retrieved from the registry so it is >a way to go with dlopen and dlsym mechanism. Great. I am glad that this seems like it might work. >Since I think all fuse

Re: [ITP] FUSE 2.8

On 7/26/16, 12:02 PM, Mark Geisert wrote: >Bill Zissimopoulos writes: >> BTW, here is another alternative that I have been mulling around. >> >[...] > >Very interesting. I'll need a little more time to investigate; github is >throwing unicorns at the moment. Y

Re: [ITP] FUSE 2.8

On 7/25/16, 11:27 PM, Mark Geisert wrote: >Bill Zissimopoulos writes: >> - Rename the package to winfsp-fuse, but have it somehow “satisfy” >> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow >> multiple *-fuse packages to exist in the setup database an

Re: [ITP] FUSE 2.8

>As I said, I'm not going to refuse your package. I was just pissed >about this discussion in conjunction with my (now) obvious >misunderstanding that we're talking about two forks of the same code. > >Please go ahead as planned, Thanks. As I see it there are the following options: -

Re: [ITP] FUSE 2.8

On 7/23/16, 10:48 AM, Corinna Vinschen wrote: >So you quoted my knee-jerk reaction but missed to quote the *real* point >of my mail. Fixed that for you: > >> > Here's an idea: You both slap yourself and start talking to each >>other. >> > >> > For the Windows *and* Cygwin world it would be

Re: [ITP] FUSE 2.8

On 7/23/16, 3:40 AM, Corinna Vinschen wrote: > >no idea what's up between you, but this discussion is gross... > >My interest in both of your projects has just dwindled considerably. Corinna, understood. I think this may have been the point. I was planning to work for a solution for how to have

Re: [ITP] FUSE 2.8

On 7/22/16, 11:01 PM, Marco Atzeri wrote: >On 23/07/2016 02:31, Bill Zissimopoulos wrote: >>Suppose I have a package XYZ that requires FUSE. Is it possible that the >> “FUSE” dependency can be satisfied by either winfsp-fuse or dokan-fuse? >> >> If that is not possible

Re: [ITP] FUSE 2.8

On 7/22/16, 12:57 PM, Marco Atzeri wrote: >On 22/07/2016 19:58, Bill Zissimopoulos wrote: >>> winfsp-fuse is a reasonable name. >>> dokan-fuse also (IMHO) >> >> In the interest of moving things forward, I am happy to rename the >> package. Is it possibl

Re: [ITP] FUSE 2.8

On 7/22/16, 12:56 PM, Adrien JUND wrote: >For information on your last release: curl -u "username" >https://api.github.com/repos/billziss-gh/winfsp/releases >=> winfsp-0.14.16197.msi - "download_count": 24 This is beginning to feel a bit weird. You seem to be rather obsessed with how many users

Re: [ITP] FUSE 2.8

>winfsp-fuse is a reasonable name. >dokan-fuse also (IMHO) In the interest of moving things forward, I am happy to rename the package. Is it possible for a package with a name winfsp-fuse to satisfy a “fuse” dependency? Bill

Re: [ITP] FUSE 2.8

On 7/22/16, 12:59 AM, Corinna Vinschen wrote: >On Jul 21 22:11, Bill Zissimopoulos wrote: >> On 7/20/16, 1:52 AM, Corinna Vinschen wrote: >> >> >We just might still want to change the name to "no+body". >> > >> >What do others on this list th

Re: [ITP] FUSE 2.8

On 7/22/16, 4:59 AM, Adrien JUND wrote: >The package should be renamed winfsp-fuse for give ability of cygwin >users to choose which solution they would like to use. Like >dokan-fuse, cbfs-fuse and other projects that offer the same >service... I am not opposed to renaming the package if that’s

Re: [ITP] FUSE 2.8

On 7/20/16, 1:52 AM, Corinna Vinschen wrote: >We just might still want to change the name to "no+body". > >What do others on this list think? What sounds better? > > "nodomain+nobody" or "no+body" Corinna, hi. I know you have asked others to chime in, but IMO you should go ahead and change it

Re: [ITP] FUSE 2.8

On 7/19/16, 2:41 AM, Corinna Vinschen wrote: > >Let's just try how it looks like. I applied the patch using >"nodomain+nobody" for now and uploaded a developer snapshot to >https://cygwin.com/snapshots/ Hi, Corinna: Here is simple SSHFS output with the patched cygwin1.dll:

Re: [ITP] FUSE 2.8

On 7/18/16, 12:43 PM, Bill Zissimopoulos wrote: >On 7/18/16, 1:19 AM, Corinna Vinschen wrote: > >>Btw., I didn't apply it yet because I was still waiting for a mailing >>list reply to https://cygwin.com/ml/cygwin/2016-06/msg00460.html >>On second thought, this didn't lo

Re: [ITP] FUSE 2.8

On 7/18/16, 1:19 AM, Corinna Vinschen wrote: >On Jul 17 01:02, Bill Zissimopoulos wrote: >>The alternatives are: >> >> 1. Accept the FUSE cygport package as is. Understand that it requires >> prior installation of WinFsp in order to properly work. >> >

Re: [ITP] FUSE 2.8

On 7/17/16, 2:18 PM, Marco Atzeri wrote: >On 17/07/2016 03:02, Bill Zissimopoulos wrote: >> This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known >> "Filesystem in Userspace" project for Linux and other platforms: [FUSE]. >> >>[snip] &g

[ITP] FUSE 2.8

This package adds FUSE 2.8 support to Cygwin. FUSE is the well-known "Filesystem in Userspace" project for Linux and other platforms: [FUSE]. FUSE file systems that use this package usually require minimal changes to run on Cygwin. For example, here are the pull requests I have submitted to SSHFS

Re: POSIX permission mapping and NULL SIDs

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

Re: POSIX permission mapping and NULL SIDs

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

Re: POSIX permission mapping and NULL SIDs

>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

Re: POSIX permission mapping and NULL SIDs

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

Re: POSIX permission mapping and NULL SIDs

On 6/24/16, 3:53 PM, "cygwin-ow...@cygwin.com on behalf of Bill Zissimopoulos" <cygwin-ow...@cygwin.com on behalf of billz...@navimatics.com> 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 ou

Re: POSIX permission mapping and NULL SIDs

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

Re: POSIX permission mapping and NULL SIDs

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

Re: POSIX permission mapping and NULL SIDs

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

POSIX permission mapping and NULL SIDs

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

Re: FUSE for Cygwin

On 6/22/16, 1:39 PM, "Jeffrey Altman" <cygwin-ow...@cygwin.com on behalf of jalt...@secure-endpoints.com> 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. Th

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

N00b question regarding Cygwin and delay loading

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

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

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

Hello, Jeffrey: On 6/18/16, 1:19 PM, "Jeffrey Altman" <cygwin-ow...@cygwin.com on behalf of jalt...@secure-endpoints.com> wrote: >On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote: >> * A directory cannot be renamed if it or any of its subdirectories >> contai

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

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

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

Re: Fork and Windows Heap

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

Re: Fork and Windows Heap

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

Fork and Windows Heap

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