Re: cygfuse (was Re: [ITP] FUSE 2.8)
>Other than that I would think that the package would be ready for >submission. Any changes to support additional projects like Dokany, etc. >could easily happen in the future when those projects are ready. Currently it is the package that is not ready for other additional projects. I saw that Mark already began to make some changes, I now have more time for this and will give a head to see how this could be made and come back with ideas of a main interface. 2016-09-20 23:12 GMT+02:00 Bill Zissimopoulos: > 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 >>https://github.com/mgeisert/cygfuse . >> >>I've also read up a little on Dokan and Dokany, so I should be able to >>better >>respond to any comments Adrien might have about the updated cygfuse. > > Mark, has there been any additional progress on this? > > Looking at the updated cygfuse I believe one change would be to rename > cygfuse.pc back to fuse.pc so that build configuration scripts can find > it. I have created a github issue for this. > > Other than that I would think that the package would be ready for > submission. Any changes to support additional projects like Dokany, etc. > could easily happen in the future when those projects are ready. > > Bill >
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 >https://github.com/mgeisert/cygfuse . > >I've also read up a little on Dokan and Dokany, so I should be able to >better >respond to any comments Adrien might have about the updated cygfuse. Mark, has there been any additional progress on this? Looking at the updated cygfuse I believe one change would be to rename cygfuse.pc back to fuse.pc so that build configuration scripts can find it. I have created a github issue for this. Other than that I would think that the package would be ready for submission. Any changes to support additional projects like Dokany, etc. could easily happen in the future when those projects are ready. Bill
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 should be part of Cygwin, as in placed in >>the >> >Cygwin >> >source tree, or just conveniently hosted on the Cygwin GitHub area. >> >> Corinna, should answer that. My understanding was that she would like to >> see this package hosted in Cygwin’s GitHub area. > >Y'all, don't get me wrong. It would be *nice* and I'd love to see more >projects under this cover or under the cygwin-apps cover on cygwin.com/ >sourceware.org, but it's not a hard requirement. I favor this as well. But at this point it is Mark’s call. Bill
Re: [ITP] FUSE 2.8
On Sep 6 21:13, Bill Zissimopoulos wrote: > On 9/5/16, 2:35 AM, Mark Geisert wrote: > >to cygfuse.cygport, etc. The doc inside some files might need updating. > > I agree with your naming changes. Recall that I basically ripped the > cygfuse package out of WinFsp so the names will have to be revisited. > > >I wasn't sure from Corinna's comments a while back (re hosting this > >package) > >whether she thought cygfuse should be part of Cygwin, as in placed in the > >Cygwin > >source tree, or just conveniently hosted on the Cygwin GitHub area. > > Corinna, should answer that. My understanding was that she would like to > see this package hosted in Cygwin’s GitHub area. Y'all, don't get me wrong. It would be *nice* and I'd love to see more projects under this cover or under the cygwin-apps cover on cygwin.com/ sourceware.org, but it's not a hard requirement. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
Herbert Stocker wrote: Maybe somebody wants to use WinFSP for Windows programs and Dokan for Cygwin programs. There should be some user setting for the case both are installed. Maybe some cygfuse-admin command could do the job. This kind of flexibility would be nice. We can of course only control the Cygwin environment though. As a first cut I've implemented an environment variable CYGFUSE that can be set to either "WinFSP" or "Dokany" (any case allowed) to select which FUSE DLL to load at runtime. Thanks, ..mark
cygfuse (was Re: [ITP] FUSE 2.8)
Mark Geisert wrote: [... some stuff ...] 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 https://github.com/mgeisert/cygfuse . I've also read up a little on Dokan and Dokany, so I should be able to better respond to any comments Adrien might have about the updated cygfuse. Thanks all, ..mark
Re: [ITP] FUSE 2.8
Hi, On 05.09.2016 22:16, Mark Geisert wrote: Currently, if WinFSP is installed on the system (determined by the existence of a particular registry key) then cygfuse attaches to the WinFSP DLL. This code needs to be extended to check whether Dokan is installed (determined by some mechanism TBD) and then attach to Dokan's DLL. And so on for other future implementations. i think so, too. However, in the sense of neutrality and in case there are both file systems installed, it should not give the one precedence over the other. That means cygfuse should not just check for available file systems and load the first found. There should be some user prece- dence. Maybe somebody wants to use WinFSP for Windows programs and Dokan for Cygwin programs. There should be some user setting for the case both are installed. Maybe some cygfuse-admin command could do the job. Just a thought, not meant as high priority, because first we must get more than one file system ready for use. Herbert Stocker
Re: [ITP] FUSE 2.8
Hi Adrien, I want to dig a little further into this... Adrien JUND wrote: I have tried to see how to integrate Dokan in cygfuse and it is currently hard linked to WinFSP and makes hard the integration for others FS. A neutral interface with common operations should be made to fix the situation. Cygfuse is intended to be the neutral interface. I'll be making cosmetic changes to it to make it more clear what belongs to cygfuse and what belongs to FUSE implementation DLLs loaded by cygfuse. Does the strategy of testing something in the environment for existence of Dokan, then if found, load a Dokan-specific DLL sound workable for you? I want to be sure I'm not assuming too much about what FUSE implementations provide. If you can be more specific about the gap between cygfuse as it is now and cygfuse being usable for you, please feel free. You could also wait for a cosmetically updated cygfuse which I hope to have in "a few days" modulo real life interruptions. Thanks much, ..mark
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 Windows-native DLL mapping FUSE 2.8 ops to/from Windows >>>file ops >>> cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP >>> >>> If that's correct, I'd like to regularize the names of things in the >>>proposed cygfuse package to accurately reflect their meaning. E.g., >>>change fuse.cygport to cygfuse.cygport, etc. The doc inside some files >>>might need updating. >> >> About cygfuse description, does the goal of cygfuse is not to wrappe >> FUSE API for user land file systems like Dokan, WinFSP, CBFS, and >> others ? >> >> I have tried to see how to integrate Dokan in cygfuse and it is >> currently hard linked to WinFSP and makes hard the integration for >> others FS. >> A neutral interface with common operations should be made to fix the >>situation. > >I believe all interested parties have agreed we want to support multiple >FUSE >implementations. cygfuse is intended to be the connector between a FUSE >implementation and Cygwin versions of FUSE apps like SSHFS and FUSEPY. >The idea >was to allow different FUSE implementations (e.g., WinFSP, Dokan, etc) >under the >hood without having to modify the Cygwin level apps SSHFS, FUSEPY, etc to >match. > >As currently implemented, cygfuse is hardwired to work with WinFSP. >That's only >a consequence of cygfuse having been provided by WinFSP's author. The >plan is >to extend cygfuse so that it can support multiple FUSE implementations of >which >one is selected at runtime. > >Currently, if WinFSP is installed on the system (determined by the >existence of >a particular registry key) then cygfuse attaches to the WinFSP DLL. This >code >needs to be extended to check whether Dokan is installed (determined by >some >mechanism TBD) and then attach to Dokan's DLL. And so on for other >future >implementations. > >I'm trying to get my understanding of the pieces and naming correct in >order to >modify the cygfuse code to be more generic and less tied to WinFSP. Mark, thank you. I agree with everything you said. Bill
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 up more reliably with this. >Sorry for the delay. I've 'git clone'd the cygfuse repository and have >been >poking around, building and testing things. 'make cygfuse-test.exe' does >build >a cygfuse-test.exe but running it yields a core dump. Exit status is 134. Cygfuse-test was really a throw-away test program that I used during my development. It simply checks that the cygfuse.dll can be loaded and the fuse_version symbol is available. Here it is in its entirety: #include int main() { return !(FUSE_VERSION == fuse_version()); } The most likely reason for the access violation is that the WinFsp DLL was not installed. I note that cygfuse calls abort() (in cygfuse.c:cygfuse_init_fail) if it cannot find the WinFsp DLL. This can be changed to provide a more informative message of course. >I'm just running it without any args. Is that abort a symptom of not >having the >WinFSP driver loaded, or something else? Cygfuse works for both 32- and >64-bit >Windows environments, right (assuming you're running the correct one)? I have tested the WinFsp FSD/DLL in both 32- and 64-bit environments. However cygfuse has only been tested in 64-bit environments so far. >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 Windows-native DLL mapping FUSE 2.8 ops to/from Windows file >ops >cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP > >If that's correct, I'd like to regularize the names of things in the >proposed >cygfuse package to accurately reflect their meaning. E.g., change >fuse.cygport >to cygfuse.cygport, etc. The doc inside some files might need updating. I agree with your naming changes. Recall that I basically ripped the cygfuse package out of WinFsp so the names will have to be revisited. >I wasn't sure from Corinna's comments a while back (re hosting this >package) >whether she thought cygfuse should be part of Cygwin, as in placed in the >Cygwin >source tree, or just conveniently hosted on the Cygwin GitHub area. Corinna, should answer that. My understanding was that she would like to see this package hosted in Cygwin’s GitHub area. Bill
Re: [ITP] FUSE 2.8
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 Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning. E.g., change fuse.cygport to cygfuse.cygport, etc. The doc inside some files might need updating. About cygfuse description, does the goal of cygfuse is not to wrappe FUSE API for user land file systems like Dokan, WinFSP, CBFS, and others ? I have tried to see how to integrate Dokan in cygfuse and it is currently hard linked to WinFSP and makes hard the integration for others FS. A neutral interface with common operations should be made to fix the situation. I believe all interested parties have agreed we want to support multiple FUSE implementations. cygfuse is intended to be the connector between a FUSE implementation and Cygwin versions of FUSE apps like SSHFS and FUSEPY. The idea was to allow different FUSE implementations (e.g., WinFSP, Dokan, etc) under the hood without having to modify the Cygwin level apps SSHFS, FUSEPY, etc to match. As currently implemented, cygfuse is hardwired to work with WinFSP. That's only a consequence of cygfuse having been provided by WinFSP's author. The plan is to extend cygfuse so that it can support multiple FUSE implementations of which one is selected at runtime. Currently, if WinFSP is installed on the system (determined by the existence of a particular registry key) then cygfuse attaches to the WinFSP DLL. This code needs to be extended to check whether Dokan is installed (determined by some mechanism TBD) and then attach to Dokan's DLL. And so on for other future implementations. I'm trying to get my understanding of the pieces and naming correct in order to modify the cygfuse code to be more generic and less tied to WinFSP. ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: Mark, hi: On 8/22/16, 12:43 PM, cygwin-apps-ow...@cygwin.com on behalf of Mark Geisert wrote: > I'm debugging some faulting test programs so this cygfuse code doesn't seem fully ready for prime time just yet. I'm sure Bill had it working so it's likely to be some kind of local issue, so it's mine to solve. 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. Sorry for the delay. I've 'git clone'd the cygfuse repository and have been poking around, building and testing things. 'make cygfuse-test.exe' does build a cygfuse-test.exe but running it yields a core dump. Exit status is 134. I'm just running it without any args. Is that abort a symptom of not having the WinFSP driver loaded, or something else? Cygfuse works for both 32- and 64-bit Windows environments, right (assuming you're running the correct one)? 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 Windows-native DLL mapping FUSE 2.8 ops to/from Windows file ops cygfuse - a Cygwin DLL allowing Cygwin SSHFS and FUSEPY to use WinFSP If that's correct, I'd like to regularize the names of things in the proposed cygfuse package to accurately reflect their meaning. E.g., change fuse.cygport to cygfuse.cygport, etc. The doc inside some files might need updating. I wasn't sure from Corinna's comments a while back (re hosting this package) whether she thought cygfuse should be part of Cygwin, as in placed in the Cygwin source tree, or just conveniently hosted on the Cygwin GitHub area. That's where I'm at. Thanks for reading. ..mark
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 further, then >>>real life >>> intervened. Something to do with where its cygport file was getting >>>package >>> source from. >> >> Directly from git? See, e.g., the cygwin package's cygport. > >OK. The cygfuse.cygport file is referring to Bill's separate GitHub >space >for source code. Not sure it ought to do that. Either my GitHub space >(as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems >better. Regarding SRC_URI I needed to solve two problems: how to build the cygfuse package given only the cygport source (which is what most other cygports seem to do) and how to build the cygfuse package directly from its own source tree for my own development purposes. This is the reason for the CYGPORT_SRC_URI and CYGPORT_SRC_DIR vars. The Makefile sets CYGPORT_SRC_URI/CYGPORT_SRC_DIR in such a way that everything can be compiled locally. In normal usage CYGPORT_SRC_URI is not set, so the source is picked up from github. The reason that the default location is "github.com/billziss-gh/cygfuse/..." is that at the time I was maintaining the project. It should be changed to “github.com/mgeisert/cygfuse/..." now of course. Bill
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 research further, then >>>real life >>> intervened. Something to do with where its cygport file was getting >>>package >>> source from. >> >> Directly from git? See, e.g., the cygwin package's cygport. > >OK. The cygfuse.cygport file is referring to Bill's separate GitHub >space >for source code. Not sure it ought to do that. Either my GitHub space >(as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems >better. > >I'm debugging some faulting test programs so this cygfuse code doesn't >seem fully ready for prime time just yet. I'm sure Bill had it working >so >it's likely to be some kind of local issue, so it's mine to solve. 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. Bill
Re: [ITP] FUSE 2.8
On Aug 22 02:43, Mark Geisert wrote: > On Wed, 17 Aug 2016, Corinna Vinschen wrote: > > > > Mark, did you find out how to move the repo under the Cygwin org > > > > in the meantime? Is it the "Import repository" functionality by > > > > any chance? > > > > > > Hi Corinna, > > > Bill and I worked it out on a different thread of this conversation. I > > > currently have a public repo mgeisert/cygfuse on GitHub. That seemed to > > > be > > > sufficient to me as maintainer. Does it need to be moved under cygwin/ ? > > > If yes, it looks like "Import Repository" is a way to do it. > > > > It doesn't *need* to be but it would be neat and helpful to have > > closley Cygwin-related projects in the Cygwin org. > > I don't have any objection to that in principle. It's hard for me to tell > if this project qualifies that way, though. No worries, it's your call. We just provide the Cygwin org for all of us to share. It would be a pity if it goes mostly unused. > Conceptually it's kind of like > a VFS layer, but the core functionality is in Bill's separate Windows-native > WinFSP dll. The Cygwin end of things is just a bunch of wrappers around > WinFSP calls all collected in a Cygwin dll. (BTW, I don't see how > transparency is supposed to work in a setup like this.) I guess you'd need to discuss this with Bill. > > > 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 further, then real > > > life > > > intervened. Something to do with where its cygport file was getting > > > package > > > source from. > > > > Directly from git? See, e.g., the cygwin package's cygport. > > OK. The cygfuse.cygport file is referring to Bill's separate GitHub space > for source code. Not sure it ought to do that. Either my GitHub space (as > I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems better. In theory it doesn't matter, as long as the github space is open to the public and the license is OSS compatible. > I'm debugging some faulting test programs so this cygfuse code doesn't seem > fully ready for prime time just yet. I'm sure Bill had it working so it's > likely to be some kind of local issue, so it's mine to solve. Ok. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
On Wed, 17 Aug 2016, Corinna Vinschen wrote: Mark, did you find out how to move the repo under the Cygwin org in the meantime? Is it the "Import repository" functionality by any chance? Hi Corinna, Bill and I worked it out on a different thread of this conversation. I currently have a public repo mgeisert/cygfuse on GitHub. That seemed to be sufficient to me as maintainer. Does it need to be moved under cygwin/ ? If yes, it looks like "Import Repository" is a way to do it. It doesn't *need* to be but it would be neat and helpful to have closley Cygwin-related projects in the Cygwin org. I don't have any objection to that in principle. It's hard for me to tell if this project qualifies that way, though. Conceptually it's kind of like a VFS layer, but the core functionality is in Bill's separate Windows-native WinFSP dll. The Cygwin end of things is just a bunch of wrappers around WinFSP calls all collected in a Cygwin dll. (BTW, I don't see how transparency is supposed to work in a setup like this.) 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 further, then real life intervened. Something to do with where its cygport file was getting package source from. Directly from git? See, e.g., the cygwin package's cygport. OK. The cygfuse.cygport file is referring to Bill's separate GitHub space for source code. Not sure it ought to do that. Either my GitHub space (as I'm the Cygwin cygfuse maintainer) or Cygwin's GitHub space seems better. I'm debugging some faulting test programs so this cygfuse code doesn't seem fully ready for prime time just yet. I'm sure Bill had it working so it's likely to be some kind of local issue, so it's mine to solve. ..mark
Re: [ITP] FUSE 2.8
Hi Mark, On Aug 17 01:26, Mark Geisert wrote: > Corinna Vinschen wrote: > > On Jul 29 11:48, Corinna Vinschen wrote: > > > On Jul 29 02:15, Mark Geisert wrote: > > > > Thanks Corinna, I've accepted the invite and filled in my profile a bit. > > > > How would I/we accept the repo as Bill mentions above? Then I guess a > > > > transfer needs to be done after that? > > > > > > I really don't know, sorry. I'm not actually using github a lot since > > > the cygwin repo is only mirrored to github. I'd guess there's some > > > kind of documentation on github explaining stuff like that...? > > > > Mark, did you find out how to move the repo under the Cygwin org > > in the meantime? Is it the "Import repository" functionality by > > any chance? > > Hi Corinna, > Bill and I worked it out on a different thread of this conversation. I > currently have a public repo mgeisert/cygfuse on GitHub. That seemed to be > sufficient to me as maintainer. Does it need to be moved under cygwin/ ? > If yes, it looks like "Import Repository" is a way to do it. It doesn't *need* to be but it would be neat and helpful to have closley Cygwin-related projects in the Cygwin org. > 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 further, then real life > intervened. Something to do with where its cygport file was getting package > source from. Directly from git? See, e.g., the cygwin package's cygport. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
Corinna Vinschen wrote: On Jul 29 11:48, Corinna Vinschen wrote: On Jul 29 02:15, Mark Geisert wrote: Corinna Vinschen wrote: On Jul 29 01:19, Mark Geisert wrote: Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. 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... I invited you with email mark AT maxrnd DOT com There appears to be a user account called mgeisert, but it has no further info attached, not even a name. Thanks Corinna, I've accepted the invite and filled in my profile a bit. How would I/we accept the repo as Bill mentions above? Then I guess a transfer needs to be done after that? I really don't know, sorry. I'm not actually using github a lot since the cygwin repo is only mirrored to github. I'd guess there's some kind of documentation on github explaining stuff like that...? Mark, did you find out how to move the repo under the Cygwin org in the meantime? Is it the "Import repository" functionality by any chance? Hi Corinna, Bill and I worked it out on a different thread of this conversation. I currently have a public repo mgeisert/cygfuse on GitHub. That seemed to be sufficient to me as maintainer. Does it need to be moved under cygwin/ ? If yes, it looks like "Import Repository" is a way to do it. 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 further, then real life intervened. Something to do with where its cygport file was getting package source from. ..mark
Re: [ITP] FUSE 2.8
On Jul 29 11:48, Corinna Vinschen wrote: > On Jul 29 02:15, Mark Geisert wrote: > > Corinna Vinschen wrote: > > > On Jul 29 01:19, Mark Geisert wrote: > > > > Bill Zissimopoulos wrote: > > > > > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: > > > > > > Ok. I did the transfer (twice, because of some ambiguous GitHub > > > > > > messages). > > > > > > Someone from cygwin’s side has to accept the repo within a day > > > > > > according > > > > > > to GitHub. > > > > > > > > > > Turns out I can transfer a repo to another user, but not to an > > > > > organization that I do not have admin rights for: > > > > > > > > > > From github’s transfer repo instructions: > > > > > << > > > > > Transfer this repository to another user or to an organization where > > > > > you > > > > > have admin rights. > > > > > > > > > > > > > > > > > > > > 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... > > > > > > I invited you with email mark AT maxrnd DOT com > > > > > > There appears to be a user account called mgeisert, but it has no further > > > info attached, not even a name. > > > > Thanks Corinna, I've accepted the invite and filled in my profile a bit. > > How would I/we accept the repo as Bill mentions above? Then I guess a > > transfer needs to be done after that? > > I really don't know, sorry. I'm not actually using github a lot since > the cygwin repo is only mirrored to github. I'd guess there's some > kind of documentation on github explaining stuff like that...? Mark, did you find out how to move the repo under the Cygwin org in the meantime? Is it the "Import repository" functionality by any chance? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: 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 name. Thanks. Great! Thank you Bill for your contribution of Cygwin support for WinFSP. Have a nice time AWOL :). ..mark
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 name. Thanks. Bill
Re: [ITP] FUSE 2.8
On Jul 29 02:15, Mark Geisert wrote: > Corinna Vinschen wrote: > > On Jul 29 01:19, Mark Geisert wrote: > > > Bill Zissimopoulos wrote: > > > > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: > > > > > Ok. I did the transfer (twice, because of some ambiguous GitHub > > > > > messages). > > > > > Someone from cygwin’s side has to accept the repo within a day > > > > > according > > > > > to GitHub. > > > > > > > > Turns out I can transfer a repo to another user, but not to an > > > > organization that I do not have admin rights for: > > > > > > > > From github’s transfer repo instructions: > > > > << > > > > Transfer this repository to another user or to an organization where you > > > > have admin rights. > > > > > > > > > > > > > > > > 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... > > > > I invited you with email mark AT maxrnd DOT com > > > > There appears to be a user account called mgeisert, but it has no further > > info attached, not even a name. > > Thanks Corinna, I've accepted the invite and filled in my profile a bit. > How would I/we accept the repo as Bill mentions above? Then I guess a > transfer needs to be done after that? I really don't know, sorry. I'm not actually using github a lot since the cygwin repo is only mirrored to github. I'd guess there's some kind of documentation on github explaining stuff like that...? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
Corinna Vinschen wrote: On Jul 29 01:19, Mark Geisert wrote: Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. 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... I invited you with email mark AT maxrnd DOT com There appears to be a user account called mgeisert, but it has no further info attached, not even a name. Thanks Corinna, I've accepted the invite and filled in my profile a bit. How would I/we accept the repo as Bill mentions above? Then I guess a transfer needs to be done after that? ..mark
Re: [ITP] FUSE 2.8
On Jul 29 01:19, Mark Geisert wrote: > Bill Zissimopoulos wrote: > > On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: > > > Ok. I did the transfer (twice, because of some ambiguous GitHub messages). > > > Someone from cygwin’s side has to accept the repo within a day according > > > to GitHub. > > > > Turns out I can transfer a repo to another user, but not to an > > organization that I do not have admin rights for: > > > > From github’s transfer repo instructions: > > << > > Transfer this repository to another user or to an organization where you > > have admin rights. > > > > > > > > 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... I invited you with email mark AT maxrnd DOT com There appears to be a user account called mgeisert, but it has no further info attached, not even a name. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: On 7/28/16, 5:17 PM, Bill Zissimopoulos wrote: Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. 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... ..mark
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: 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 call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? I agree. Win7 support will return soon. I am trying to get this fixed before I leave tomorrow, but I also have some real (as in paying) work to do so no guarantees. Just wanted to let you know that I have made a new public release of WinFsp, which should correctly work on all versions of Windows 7 and above. You can download it from here: http://www.secfs.net/winfsp/download/ Excellent! Thanks for your patience and diligence on this. I look forward to using WinFSP and taking over maintenance of the Cygwin end of it. Cheers, ..mark
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 call obviously but do you want to forgo Win 7 support when >>>many >>> of the >>> kind of developers who might be interested in FUSE on Windows are >>> delaying or >>> not bothering to upgrade to Win 8.x or Win 10 for various reasons? >> >> I agree. Win7 support will return soon. I am trying to get this fixed >> before I leave tomorrow, but I also have some real (as in paying) work >>to >> do so no guarantees. Just wanted to let you know that I have made a new public release of WinFsp, which should correctly work on all versions of Windows 7 and above. You can download it from here: http://www.secfs.net/winfsp/download/ Thanks. Bill
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://github.com/cygwin Every Cygwin-related project is welcome. >>> >>> If Mark agrees, I am happy to transfer ownership of the github repo to >>>the >>> cygwin@github. >> >>Sounds like a fine idea! > >Ok. I did the transfer (twice, because of some ambiguous GitHub messages). >Someone from cygwin’s side has to accept the repo within a day according >to GitHub. Turns out I can transfer a repo to another user, but not to an organization that I do not have admin rights for: From github’s transfer repo instructions: << Transfer this repository to another user or to an organization where you have admin rights. >> Bill
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. >> >> If Mark agrees, I am happy to transfer ownership of the github repo to >>the >> cygwin@github. > >Sounds like a fine idea! Ok. I did the transfer (twice, because of some ambiguous GitHub messages). Someone from cygwin’s side has to accept the repo within a day according to GitHub. Bill
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: 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 cygfuse anyway. Thank you very much for agreeing to become the maintainer for [CYGFUSE]. Please consider this post as my public announcement that I am relicensing the [CYGFUSE] files under the BSD 2-clause license and that I am assigning maintainership to Mark. The project has been updated with a README and a LICENSE file that state the same. Source files have been updated to reflect the license change as well. Mark, if at some point you 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? github Cygwin org? https://github.com/cygwin Every Cygwin-related project is welcome. If Mark agrees, I am happy to transfer ownership of the github repo to the cygwin@github. Sounds like a fine idea! ..mark
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 cygfuse anyway. >> >> Thank you very much for agreeing to become the maintainer for [CYGFUSE]. >> Please consider this post as my public announcement that I am >>relicensing >> the [CYGFUSE] files under the BSD 2-clause license and that I am >>assigning >> maintainership to Mark. >> >> The project has been updated with a README and a LICENSE file that state >> the same. Source files have been updated to reflect the license change >>as >> well. >> >> Mark, if at some point you 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? > >github Cygwin org? > >https://github.com/cygwin > >Every Cygwin-related project is welcome. If Mark agrees, I am happy to transfer ownership of the github repo to the cygwin@github. Bill
Re: [ITP] FUSE 2.8
On Jul 28 12:58, Mark Geisert wrote: > 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 cygfuse anyway. > > > > Thank you very much for agreeing to become the maintainer for [CYGFUSE]. > > Please consider this post as my public announcement that I am relicensing > > the [CYGFUSE] files under the BSD 2-clause license and that I am assigning > > maintainership to Mark. > > > > The project has been updated with a README and a LICENSE file that state > > the same. Source files have been updated to reflect the license change as > > well. > > > > Mark, if at some point you 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 > > I'll likely host it from my private http/ftp server at maxrnd.com, at least > initially. The cygutils package was there for review so I know it would > work. I've been looking at some of the public repositories over time but > haven't moved to one, largely because I haven't really needed it. > > OK on your changes above including the minor correction you made afterwards. > Cheers, Again, we have the Cygwin org @ github, https://github.com/cygwin. You can simple put your repo under this cover. Alternatively you can also get your own repo under the cygwin-apps cover at cygwin.com/sourceware.org: https://sourceware.org/cygwin-apps/ https://sourceware.org/git/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
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 cygfuse anyway. > > Thank you very much for agreeing to become the maintainer for [CYGFUSE]. > Please consider this post as my public announcement that I am relicensing > the [CYGFUSE] files under the BSD 2-clause license and that I am assigning > maintainership to Mark. > > The project has been updated with a README and a LICENSE file that state > the same. Source files have been updated to reflect the license change as > well. > > Mark, if at some point you 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? github Cygwin org? https://github.com/cygwin Every Cygwin-related project is welcome. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
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 cygfuse anyway. Thank you very much for agreeing to become the maintainer for [CYGFUSE]. Please consider this post as my public announcement that I am relicensing the [CYGFUSE] files under the BSD 2-clause license and that I am assigning maintainership to Mark. The project has been updated with a README and a LICENSE file that state the same. Source files have been updated to reflect the license change as well. Mark, if at some point you 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 I'll likely host it from my private http/ftp server at maxrnd.com, at least initially. The cygutils package was there for review so I know it would work. I've been looking at some of the public repositories over time but haven't moved to one, largely because I haven't really needed it. OK on your changes above including the minor correction you made afterwards. Cheers, ..mark
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
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 cygfuse anyway. Thank you very much for agreeing to become the maintainer for [CYGFUSE]. Please consider this post as my public announcement that I am relicensing the [CYGFUSE] files under the BSD 2-clause license and that I am assigning maintainership to Mark. The project has been updated with a README and a LICENSE file that state the same. Source files have been updated to reflect the license change as well. Mark, if at some point you 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. I thought your FUSE implementation had to be compiled for >Cygwin, >in order to make use of the cygfuse glue logic. But instead you have a >native >Windows FUSE implementation? Won't you have ABI (not API) problems >connecting >those two pieces, depending on how the FUSE guts are implemented? >Apologies if >you've sorted that all out; don't want to hold you up talking about >solved aspects. Yes. I have a FUSE implementation that works for native and Cygwin programs. The ABI was indeed a bit of an issue, hence my use of fsp_fuse_* symbols vs fuse_* symbols. Quick example: instead of offering a fuse_loop symbol, WinFsp offers an fsp_fuse_loop symbol. Then fuse_new is coded as (for native): static inline int fuse_loop(struct fuse *f) { return fsp_fuse_loop(fsp_fuse_env(), f); } Similar code is used in the cygfuse DLL (in fact the same fuse_loop definition is used on native and Cygwin through macro (ab)use). The fsp_fuse_env() captures the “environment” which includes things like the local MSVCRT/Cygwin malloc, etc. I also make sure not to use long anywhere (since its size is different on Win64 vs Cygwin64). I have some more information on this scheme here: http://www.secfs.net/winfsp/blog/files/sshfs-port-case-study-step-2.html >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 cygfuse anyway. Excellent. I will change the project to BSD and will explicitly say that I am assigning ownership to you in the README/LICENSE files. Bill
Re: [ITP] FUSE 2.8
Bill Zissimopoulos wrote: 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 (GetOverlappedResultEx). It's your call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? I agree. Win7 support will return soon. I am trying to get this fixed before I leave tomorrow, but I also have some real (as in paying) work to do so no guarantees. Is there an alternative to that particular API that would allow Win 7 support? This particular problem has been fixed by a combination of WaitForSingleObject and GetOverlappedResult (GetOverlappedResultEx is really a wrapper around WaitForSingeObject). But I have also discovered another issue that is less trivial. Argh. Your detailed build instructions worked fine for me. I'll be unable to test until I set up a Win 8.x or Win 10 VM at some point. But so far so good. 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 :) . Since this cygfuse glue DLL is a separate package from your FUSE implementation, I guess it'll need a separate ITP. Will you do the initial package upload and then turn maintainership over to me, or would you prefer I own the package from the start? Either way OK with me. I guess whoever will be doing the initial upload should be the ITP submitter as well. Actually my ITP submission is this cygfuse DLL. Based on what you write above it looks like you are happy to become the maintainer(?). If yes, it would perhaps make sense for you to resubmit the package. Please let me know if you agree and I will place the package under the BSD and transfer ownership to you on GitHub. My mistake. I thought your FUSE implementation had to be compiled for Cygwin, in order to make use of the cygfuse glue logic. But instead you have a native Windows FUSE implementation? Won't you have ABI (not API) problems connecting those two pieces, depending on how the FUSE guts are implemented? Apologies if you've sorted that all out; don't want to hold you up talking about solved aspects. 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 cygfuse anyway. Thanks much, ..mark
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 (GetOverlappedResultEx). > >It's your call obviously but do you want to forgo Win 7 support when many >of the >kind of developers who might be interested in FUSE on Windows are >delaying or >not bothering to upgrade to Win 8.x or Win 10 for various reasons? I agree. Win7 support will return soon. I am trying to get this fixed before I leave tomorrow, but I also have some real (as in paying) work to do so no guarantees. >Is there an alternative to that particular API that would allow Win 7 >support? This particular problem has been fixed by a combination of WaitForSingleObject and GetOverlappedResult (GetOverlappedResultEx is really a wrapper around WaitForSingeObject). But I have also discovered another issue that is less trivial. >Your detailed build instructions worked fine for me. I'll be unable to >test >until I set up a Win 8.x or Win 10 VM at some point. But so far so good. I am going to really try to get that Win 7 supporting build out by the end of Thursday (Pacific time). >Since this cygfuse glue DLL is a separate package from your FUSE >implementation, >I guess it'll need a separate ITP. Will you do the initial package >upload and >then turn maintainership over to me, or would you prefer I own the >package from >the start? Either way OK with me. I guess whoever will be doing the >initial >upload should be the ITP submitter as well. Actually my ITP submission is this cygfuse DLL. Based on what you write above it looks like you are happy to become the maintainer(?). If yes, it would perhaps make sense for you to resubmit the package. Please let me know if you agree and I will place the package under the BSD and transfer ownership to you on GitHub. Bill
Re: [ITP] FUSE 2.8
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 (GetOverlappedResultEx). It's your call obviously but do you want to forgo Win 7 support when many of the kind of developers who might be interested in FUSE on Windows are delaying or not bothering to upgrade to Win 8.x or Win 10 for various reasons? Is there an alternative to that particular API that would allow Win 7 support? PS: I am going AWOL this Friday. If you don't mind my asking, do you mean for the day, for a couple weeks, for ever, ??? :-D Sorry! I am realizing now this could be taken in a darker way than I intended. I just meant I am going on vacation and that I have to attend to some family matters. It is likely I will not be able to participate in discussions for a few weeks. Appreciate knowing the time frame :). Your detailed build instructions worked fine for me. I'll be unable to test until I set up a Win 8.x or Win 10 VM at some point. But so far so good. Since this cygfuse glue DLL is a separate package from your FUSE implementation, I guess it'll need a separate ITP. Will you do the initial package upload and then turn maintainership over to me, or would you prefer I own the package from the start? Either way OK with me. I guess whoever will be doing the initial upload should be the ITP submitter as well. Thanks, ..mark
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 >> $ ./configure > >On my test machine (Win7 64, Cygwin 64) I get the errors shown below. >But first let me ask... 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). >> PS: I am going AWOL this Friday. > >If you don't mind my asking, do you mean for the day, for a couple >weeks, for ever, ??? :-D Sorry! I am realizing now this could be taken in a darker way than I intended. I just meant I am going on vacation and that I have to attend to some family matters. It is likely I will not be able to participate in discussions for a few weeks. >Here is the tail end of the ./configure output: >8< >configure: error: Package requirements (fuse >= 2.3 glib-2.0 gthread- >2.0) were not met: > >No package 'fuse' found >No package 'glib-2.0' found >No package 'gthread-2.0' found >>8 > >The following shows I have glib2 installed. I can't find a gthread >package for Cygwin. I've compiled cygfuse; what cygport command will >satisfy the package reference for configure (newbie question this)? > >$ cygcheck -c | egrep 'fuse|glib|gthread' >libglib2.0_0 2.46.2-4 OK You will need libglib2.0-devel. This includes gthread-2.0 as well. The reason it cannot find the FUSE package is because the cygfuse package has not been “installed”. Here is how I build and install it. # how to build $ cd cygfuse $ git clean -dfx $ make cygport # list tarball contents $ tar taf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz # how to install $ tar -C/ -xaf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz # how to uninstall $ tar taf fuse-2.8-4.x86_64/dist/fuse/fuse-2.8-4.tar.xz | sed 's@.*@/&@' | xargs rm You can verify that the cygfuse package has been installed properly: $ ls -l /usr/bin/cygfuse* -rwxr-xr-x 1 billziss None 14336 Jul 27 10:32 /usr/bin/cygfuse-2.8.dll $ ls -l /usr/include/fuse/ total 28 -rw-r--r-- 1 billziss None 7052 Jul 27 10:32 fuse.h -rw-r--r-- 1 billziss None 3912 Jul 27 10:32 fuse_common.h -rw-r--r-- 1 billziss None 3557 Jul 27 10:32 fuse_opt.h -rw-r--r-- 1 billziss None 8455 Jul 27 10:32 winfsp_fuse.h $ ls -l /usr/lib/libfuse* -rw-r--r-- 1 billziss None 19626 Jul 27 10:32 /usr/lib/libfuse-2.8.dll.a lrwxrwxrwx 1 billziss None17 Jul 27 10:32 /usr/lib/libfuse.dll.a -> libfuse-2.8.dll.a $ ls -ls /usr/lib/pkgconfig/fuse.pc 1 -rw-r--r-- 1 billziss None 190 Jul 27 10:32 /usr/lib/pkgconfig/fuse.pc After this SSHFS configure should be able to find the fuse.pc pkg-config file and complete the SSHFS configuration. Bill
Re: [ITP] FUSE 2.8
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 > $ ./configure On my test machine (Win7 64, Cygwin 64) I get the errors shown below. But first let me ask... > PS: I am going AWOL this Friday. If you don't mind my asking, do you mean for the day, for a couple weeks, for ever, ??? Thanks, ..mark Here is the tail end of the ./configure output: 8< checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for library containing dlsym... none required checking OpenSSH version... 6.9 >= 4.4, disabling NODELAY workaround checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for SSHFS... no configure: error: Package requirements (fuse >= 2.3 glib-2.0 gthread- 2.0) were not met: No package 'fuse' found No package 'glib-2.0' found No package 'gthread-2.0' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables SSHFS_CFLAGS and SSHFS_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. >8 The following shows I have glib2 installed. I can't find a gthread package for Cygwin. I've compiled cygfuse; what cygport command will satisfy the package reference for configure (newbie question this)? $ cygcheck -c | egrep 'fuse|glib|gthread' libglib2.0_0 2.46.2-4 OK
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 - The implementation of cygfuse.dll; this is WinFsp specific at this time. - fuse.pc.in - Pkg-config file. - inc/fuse - FUSE headers from the WinFsp project. [NOTE: The FUSE headers may give the future maintainer some trouble. They are admittedly a convoluted way of doing things. At the time I wrote them I wanted them to serve as public headers offering a FUSE API for native *and* Cygwin apps. I also wanted to have the option of not needing to link with a libfuse.a or cygfuse.dll, thence the heavy use of “static inline”. I expect that a future maintainer would refactor those heavily or perhaps ditch them altogether and switch to the libfuse headers.] To build the FUSE package, try: $ make cygport $ cd fuse-2.8-4.x86_64/dist/fuse/ $ tar -C/ -xaf fuse-2.8-4.tar.xz To test that things work, clone my sshfs repo from: https://github.com/billziss-gh/sshfs And issue the following commands: $ autoreconf -i $ ./configure $ make $ ./sshfs -o idmap=user user@host: Y: # do this from a non-admin prompt ... $ pkill sshfs I have not changed the license yet, but will do so if Mark (or someone else) takes over the repo. Bill PS: I am going AWOL this Friday.
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 wrapper in this fuse project should propose the >same FUSE VERSION, >I will need some time for updating it Dokan fuse that is currently 2.7 >when WinFSP is 2.8. I agree. Bill
Re: [ITP] FUSE 2.8
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. Since I think all fuse wrapper in this fuse project should propose the same FUSE VERSION, I will need some time for updating it Dokan fuse that is currently 2.7 when WinFSP is 2.8. Thank you Mark Geisert for willing to maintain it ! 2016-07-26 20:38 GMT+02:00 Bill Zissimopoulos: > 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 and the user >>> chooses which one they want. My understanding based on Marco’s answer is >>> that this is not currently supported by Cygwin’s dependency system. >> >>You could define a package "fuse" with no contents and a dependency on >>package "winfsp-fuse". Then later when/if another FUSE implementation >>becomes available, "somebody" could replace the "fuse" package with >>whatever is required to get alternatives support for the variants. > > BTW, here is another alternative that I have been mulling around. > > I can take the current Cygwin package source, place it under a liberal > license like the BSD and create a separate project out of it. The intent > of the new project would be to support different FUSE solutions for > Windows using a *single* package. Currently it only supports WinFsp, but > it could be modified to support Dokany or other solutions. > > There are many benefits to such an approach IMO: > > - A single FUSE package and a single cygfuse.dll. > - Works out of the box with all supported Windows user mode file system > solutions. > - No changes in Cygwin’s dependency system or setup.exe required. > - No user confusion. > > The current FUSE package is actually very simple. It looks in the registry > to see if/where WinFsp is installed and then loads the WinFsp DLL using > dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same > technique could work with Dokany or other solution. > > https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse > > To clarify I do not volunteer to maintain such a project. Only to > kickstart it by contributing the existing package code. I would hope that > another maintainer emerges, one who is both unaffiliated to the existing > projects (Dokany, WinFsp, etc.) to ensure fairness and one that has > Cygwin’s interests in mind. > > Let me know. > > Bill >
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. Yes, I noticed that. I think it is back up. >If this turns out to be a workable solution, I am willing to be maintainer >of the glue library Bill is offering. Excellent! Please let me know. Bill
Re: [ITP] FUSE 2.8
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. Could the Dokany folks consider whether this kind of wrapping might work for them too? I'm guessing they'll have a different a list of symbols to be dlsym'd (unless there's a common API) and possibly a different method to determine whether their driver is installed. If this turns out to be a workable solution, I am willing to be maintainer of the glue library Bill is offering. Thanks, ..mark -- captcha: durability
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 and the user >> chooses which one they want. My understanding based on Marco’s answer is >> that this is not currently supported by Cygwin’s dependency system. > >You could define a package "fuse" with no contents and a dependency on >package "winfsp-fuse". Then later when/if another FUSE implementation >becomes available, "somebody" could replace the "fuse" package with >whatever is required to get alternatives support for the variants. BTW, here is another alternative that I have been mulling around. I can take the current Cygwin package source, place it under a liberal license like the BSD and create a separate project out of it. The intent of the new project would be to support different FUSE solutions for Windows using a *single* package. Currently it only supports WinFsp, but it could be modified to support Dokany or other solutions. There are many benefits to such an approach IMO: - A single FUSE package and a single cygfuse.dll. - Works out of the box with all supported Windows user mode file system solutions. - No changes in Cygwin’s dependency system or setup.exe required. - No user confusion. The current FUSE package is actually very simple. It looks in the registry to see if/where WinFsp is installed and then loads the WinFsp DLL using dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same technique could work with Dokany or other solution. https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse To clarify I do not volunteer to maintain such a project. Only to kickstart it by contributing the existing package code. I would hope that another maintainer emerges, one who is both unaffiliated to the existing projects (Dokany, WinFsp, etc.) to ensure fairness and one that has Cygwin’s interests in mind. Let me know. Bill
Re: [ITP] FUSE 2.8
Adrien JUND writes: > >You could define a package "fuse" with no contents and a dependency on > >package "winfsp-fuse". Then later when/if another FUSE implementation > >becomes available, "somebody" could replace the "fuse" package with > >whatever is required to get alternatives support for the variants. > I have not officially open request now but right after we found a > solution to handle fuse wrapper packages, > I will apply for dokan as well as winfsp. > > Also, I think that packages binary dependent to a fuse wrapper would not work > if it is another wrapper that is installed. > So shall we not just let the package dependent to fuse, explicit the > wrapper that he will use ? Erm, I'm belatedly comprehending it's two independent FUSE implementations and not two versions with some common history. OK. If there's a documented binary API at some level of the FUSE definition that both implementations provide then that's what the proposed "fuse" package could export. Both implementations would then independently supply code that meets the API. I'm not sure how much extra work this means for both projects. If a common API-level interface is unworkable for whatever reason, then we'll just have to live with two independent fuse implementations. Tools like sshfs will have to be supplied by both projects and will only work with the correct underlying FUSE implementation. Something alternatives-like would be nice for an end user to switch between implementations, but I don't know if that's workable. Should it be possible to have both implementations installed at the same time? ..mark -- captcha: homely
Re: [ITP] FUSE 2.8
>You could define a package "fuse" with no contents and a dependency on >package "winfsp-fuse". Then later when/if another FUSE implementation >becomes available, "somebody" could replace the "fuse" package with >whatever is required to get alternatives support for the variants. I have not officially open request now but right after we found a solution to handle fuse wrapper packages, I will apply for dokan as well as winfsp. Also, I think that packages binary dependent to a fuse wrapper would not work if it is another wrapper that is installed. So shall we not just let the package dependent to fuse, explicit the wrapper that he will use ? 2016-07-26 10:45 GMT+02:00 Herbert Stocker: > Hi all, > > On 7/26/2016 8:27 AM, Mark Geisert wrote: >> >> You could define a package "fuse" with no contents and a dependency on >> package "winfsp-fuse". Then later when/if another FUSE implementation >> becomes available, "somebody" could replace the "fuse" package with >> whatever is required to get alternatives support for the variants. > > > Does setup.exe already have a provision in the GUI to ask the user > which one they want to chose if two or more packages are able to > provide the (empty) fuse package? > >> I'm wondering if "fuse-" is a better name template than "-fuse" in >> order to keep the variants near each other in setup.exe's displays. > > > good point. > > > Herbert Stocker
Re: [ITP] FUSE 2.8
Hi all, On 7/26/2016 8:27 AM, Mark Geisert wrote: You could define a package "fuse" with no contents and a dependency on package "winfsp-fuse". Then later when/if another FUSE implementation becomes available, "somebody" could replace the "fuse" package with whatever is required to get alternatives support for the variants. Does setup.exe already have a provision in the GUI to ask the user which one they want to chose if two or more packages are able to provide the (empty) fuse package? I'm wondering if "fuse-" is a better name template than "-fuse" in order to keep the variants near each other in setup.exe's displays. good point. Herbert Stocker
Re: [ITP] FUSE 2.8
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 and the user > chooses which one they want. My understanding based on Marco’s answer is > that this is not currently supported by Cygwin’s dependency system. You could define a package "fuse" with no contents and a dependency on package "winfsp-fuse". Then later when/if another FUSE implementation becomes available, "somebody" could replace the "fuse" package with whatever is required to get alternatives support for the variants. I'm wondering if "fuse-" is a better name template than "-fuse" in order to keep the variants near each other in setup.exe's displays. ..mark
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: - Accept/reject the current FUSE package as it has been submitted or with requested corrections, fixes, etc. However the package has received no plus/minus votes at this time. - 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 and the user chooses which one they want. My understanding based on Marco’s answer is that this is not currently supported by Cygwin’s dependency system. Bill
Re: [ITP] FUSE 2.8
On Jul 23 18:33, Bill Zissimopoulos wrote: > 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 *much* preferrable if > >>you > >> > work together and create a single, unified FUSE concept, rather than > >> > having two projects doing almost, but not entirely, the same thing, > >> > Worse, given that FUSE only makes sense if user-space filesystems > >>exist, > >> > we now have two FUSE concepts with a disjunct set of user-space > >>drivers. > > > >> I was planning to work for a solution for how to have multiple *-fuse > >> packages coexist based on Marco’s great answer. > > > >Which is not the answer I'd expected since it completely ignores the > >part about "talking to each other", "single FUSE concept" and > >"collaboration". > > Corinna, I apologize to you and the list for not being on my best > behavior. However… > > I *have* contributed to Dokany. Despite the fact that my own project is > independent and not a Dokan fork (and has a completely different This is one detail I missed here. If this has been mentioned earlier I apologise for not noticing it. I was under the implression WinFsp and dokany are from the same source code base, > design/architecture), a couple of days ago I suggested on their mailing > list that I would still work with them. The events of the last couple of > days changed my mind. > > I work on my project(s) because I can and because I find that it is fun, > even when I am debugging for 2 days why the LazyWriter hangs in some > obscure kernel corner. If it gets too political it stops being fun. If I > am forced to work on something I would rather not, it stops being fun too. > > I want to contribute to Cygwin, because I have been a user since the early > 2000’s and because I cannot live on Windows without it. I thought I had > something to contribute after all this time. Unfortunately it looks like > the price of admission may be higher than I am willing to pay at this time. 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, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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 *much* preferrable if >>you >> > work together and create a single, unified FUSE concept, rather than >> > having two projects doing almost, but not entirely, the same thing, >> > Worse, given that FUSE only makes sense if user-space filesystems >>exist, >> > we now have two FUSE concepts with a disjunct set of user-space >>drivers. > >> I was planning to work for a solution for how to have multiple *-fuse >> packages coexist based on Marco’s great answer. > >Which is not the answer I'd expected since it completely ignores the >part about "talking to each other", "single FUSE concept" and >"collaboration". Corinna, I apologize to you and the list for not being on my best behavior. However… I *have* contributed to Dokany. Despite the fact that my own project is independent and not a Dokan fork (and has a completely different design/architecture), a couple of days ago I suggested on their mailing list that I would still work with them. The events of the last couple of days changed my mind. I work on my project(s) because I can and because I find that it is fun, even when I am debugging for 2 days why the LazyWriter hangs in some obscure kernel corner. If it gets too political it stops being fun. If I am forced to work on something I would rather not, it stops being fun too. I want to contribute to Cygwin, because I have been a user since the early 2000’s and because I cannot live on Windows without it. I thought I had something to contribute after all this time. Unfortunately it looks like the price of admission may be higher than I am willing to pay at this time. Thank you and regards, Bill
Re: [ITP] FUSE 2.8
On Jul 23 16:43, Bill Zissimopoulos wrote: > 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. 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 *much* preferrable if you > > work together and create a single, unified FUSE concept, rather than > > having two projects doing almost, but not entirely, the same thing, > > Worse, given that FUSE only makes sense if user-space filesystems exist, > > we now have two FUSE concepts with a disjunct set of user-space drivers. > I was planning to work for a solution for how to have multiple *-fuse > packages coexist based on Marco’s great answer. Which is not the answer I'd expected since it completely ignores the part about "talking to each other", "single FUSE concept" and "collaboration". > If you do not believe > there is any interest any more please let me know. I was talking about *my* interest. Naturally I'm not speaking for the entire group of maintainers. I wouldn't block a package if there's no good reason like licensing problems or a package completly ignoring collision with other, existing packages. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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 multiple *-fuse packages coexist based on Marco’s great answer. If you do not believe there is any interest any more please let me know. Bill
Re: [ITP] FUSE 2.8
On Jul 23 00:23, Bill Zissimopoulos wrote: > 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 my project has. Hint: GitHub is not the primary place where > I make binary releases. > > >You seem to also don't know how many people use it. > > :-D > > Ok, I will make sure to contact you next time I need to read web server > stats. Guys, no idea what's up between you, but this discussion is gross. Here's an idea: You both slap yourself and start talking to each other. For the Windows *and* Cygwin world it would be *much* preferrable if you work together and create a single, unified FUSE concept, rather than having two projects doing almost, but not entirely, the same thing, Worse, given that FUSE only makes sense if user-space filesystems exist, we now have two FUSE concepts with a disjunct set of user-space drivers. Great :( My interest in both of your projects has just dwindled considerably. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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 it looks like we would have to have winfsp-sshfs >> or dokan-sshfs, etc. which IMO is less desirable. Marco, this is very useful information. Thank you. Allow me to take a couple of days to digest it before I come back with a more detailed answer. Bill
Re: [ITP] FUSE 2.8
On 23/07/2016 02:31, Bill Zissimopoulos wrote: 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 possible for a package with a name winfsp-fuse to satisfy a “fuse” dependency? It is not clear to me what you mean. If some package depends on winfsp-fuse, the dependency will be winfsp-fuse. winfsp-fuse will require the external package winfsp. My apologies for not making it clearer. What I meant to say is this: 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 it looks like we would have to have winfsp-sshfs or dokan-sshfs, etc. which IMO is less desirable. Bill It depends on the type of dependency - The hard coded dependency is based on dll's example : octave dll requires the readline dll provided by the package libreadline7 $ cygcheck /usr/bin/cygoctave-3.dll |grep readline E:\cygwin64\bin\cygreadline7.dll $ cygcheck -f $(cygpath -u 'E:\cygwin64\bin\cygreadline7.dll') libreadline7-6.3.8-1 In this case the dependency is hard coded in the octave binary itself. We don't have a way (yet) to provide the same dll from two different packages. In theory it can be done with pre/prost install scripts that copy and remove dll's in "/usr/bin" but it will be tricky. We can not use links with dll's on cygwin for windows loader constrain. - The dependency is based on command ls -l /usr/bin/automake lrwxrwxrwx 1 marco Administrators 34 Aug 3 2013 /usr/bin/automake -> /usr/share/autotools/am-wrapper.sh 64 $ cygcheck -f /usr/share/autotools/am-wrapper.sh automake-9-1 $ cygcheck -cd |grep automake automake9-1 automake1.101.10.3-2 automake1.111.11.6-2 automake1.121.12.6-2 automake1.131.13.4-1 automake1.141.14.1-2 automake1.151.15-1 automake1.4 1.4p6-11 automake1.5 1.5-11 automake1.6 1.6.3-12 automake1.7 1.7.9-11 automake1.8 1.8.5-11 automake1.9 1.9.6-11 automake is a wrapper package that can be defined to match the needed version and pull all the versions $ automake --version automake (GNU automake) 1.14.1 $ cygcheck-dep -r automake automake: requires ( automake1.10 automake1.11 automake1.12 automake1.13 automake1.14 automake1.15 automake1.4 automake1.5 automake1.6 automake1.7 automake1.8 automake1.9 bash gawk ) Alternatives can also be used to manage command dependency $ alternatives --display unison unison - status is auto. link currently points to /usr/bin/unison-2.48 /usr/bin/unison-2.48 - priority 2048 Current `best' version is /usr/bin/unison-2.48. specially when you need only one variant installed, but several are potentiall available: $ cygcheck -cd |grep unison unison2.48 2.48.3-2 $ cygcheck -p "bin/unison-" Found 7 matches for bin/unison- unison2.27-2.27.157-4 - unison2.27: Synchronize ... unison2.32-2.32.52-4 - unison2.32: Synchronize ... unison2.40-2.40.102-1 - unison2.40: Synchronize .. unison2.45-2.45.28-1 - unison2.45: Synchronize .. unison2.48-2.48.3-1 - unison2.48: Synchronize .. unison2.48-2.48.3-2 - unison2.48: Synchronize .. unison2.49-2.49.543-1 - unison2.49: Synchronize .. Regards Marco PS: today there is only one case of packages providing same name dll's and the solution is sub-optimal and working only as - there is a preferred order openblas cygblas-0.dll is preferred versus lapack one. - the maintainer is the same: me More packages with the same dll collision will require to work on pre/prost install scripts general solution.
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 possible for a package with a name winfsp-fuse to >>satisfy a >> “fuse” dependency? > >It is not clear to me what you mean. > >If some package depends on winfsp-fuse, the dependency will be >winfsp-fuse. > >winfsp-fuse will require the external package winfsp. My apologies for not making it clearer. What I meant to say is this: 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 it looks like we would have to have winfsp-sshfs or dokan-sshfs, etc. which IMO is less desirable. Bill
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 my project has. Hint: GitHub is not the primary place where I make binary releases. >You seem to also don't know how many people use it. :-D Ok, I will make sure to contact you next time I need to read web server stats. Bill
Re: [ITP] FUSE 2.8
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 possible for a package with a name winfsp-fuse to satisfy a “fuse” dependency? Bill It is not clear to me what you mean. If some package depends on winfsp-fuse, the dependency will be winfsp-fuse. winfsp-fuse will require the external package winfsp. Regards Marco
Re: [ITP] FUSE 2.8
Take a step back, Bill :) Here I am only concerned about a non-official fuse project "fuse" willing to use the fuse name and that would fool cygwin users. Since I never tested your solution, I only reuse your own sentence from dokan Google groups/reddit but if you continue to say that I spread rumors, I will be happy to show every of your own words. Dokan is also always in trending projects for the current day/week when a release is made on reddit. You will learn the truth that there is a different in the number of "Stars" and the number of people/bot who really use the project. 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 >You do not know how many people use WinFsp .. >Furthermore being the number 1 trending project on GitHub (for the C language) >certainly shows some favorable feedback. You seem to also don't know how many people use it. >I note that you use my own file system test suites to test your file systems Yes, we use some of your file system test suites since you propose to use it for testing Dokan at first, should we not ? We also use tools that we created and others from Microsoft. I don't understand your point here :( >takes file system semantic correctness far more seriously than Dokany Yes Dokan come from far, we changed a lot and we keep going on this way Please be my guess, here is the result of 2 years of works: https://github.com/dokan-dev/dokany/graphs/contributors http://isitmaintained.com/project/dokan-dev/dokany >could enumerate all of Dokany’s failings, but I will spare you the >embarrassment. There is no embarrassment Bill ! We already told you that we would be please to have a feedback from you on google groupe. Having issues and fixing it is the only goal here. It is even why we revived the project ! Fixing and improving it! Be also my guess for it. As an example, you added test suits (keep the good work !), we use them and we fixed issues if there were. Dokan come from far since it was an old project and there is nobody that can say we didn't do our best and that we didn't take care of ALL issues. It is also a project that showed his strange during the age ! Normally I wouldn't answer to such message as you did but I seens you are using the same arguments on every conversation comparing WinFSP/Dokan, I have feel that I need to make things clear. If you wanna continue this conversation, please do not use this cygwin thread and lets continue how winfsp-fuse and dokan-fuse can be added to cygwin packages we a correct dependancy. Liryna 2016-07-22 19:55 GMT+02:00 Bill Zissimopoulos: > 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 what the Cygwin > community wants. > > However I note that this may create the following problem. Packages that > depend on FUSE will need to have that dependency satisfied by a number of > different *-fuse packages. Perhaps the dependency system in Cygwin is > flexible enough to support this (I don’t know). > > For example I am planning to follow up this submission with SSHFS and > FUSEPY submissions. I would like to make these packages depend on a FUSE > package, so that we do not end up with a winfsp-sshfs package, a > dokan-sshfs package, etc. Even more importantly I would like SSHFS and > FUSEPY to build/run out of the box without having to add special logic for > winfsp-fuse vs dokan-fuse, etc. > > >>The official fuse window integration is an official request made by >>devs on WPDEV. This request is well placed on the top so it is >>probably only a question of time before windows do it in the same time >>as the Linux subsystem integration. >>https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-u >>buntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-suppo >>rt-in-wsl > > I am sorry, but having worked for Microsoft this is definitely wishful > thinking. If anything Microsoft would likely do it themselves. Heck I > might just rejoin them and do it for them ;) > >>I also would like to point out that WinFSP has absolutely no feedback >>of any kind by users and has not been tested on all windows versions. >>I think Kernel drivers should at least have some feedback and known as >>used in production before choosing to be distributed as cygwin >>package. >>Unstable kernel drivers can create severity damage in case of BSOD >>like windows or user files corruption. >> >>These analyses are probably severe but for the good of cygwin users, >>integrate kernel driver dependence should be well thought before >>making the step. > > Rubbish! > > I am sorry that you are so upset Liryna that I decided to create my own >
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 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 to “no+body”. > >Done. Excellent. Let me know if you wish for me to test the change. >> I also would ask others to chime in regarding this package and >> specifically if it is one they would like to see in Cygwin. >> >> I am also unclear on what the next steps are regarding this package >> submission. Does the package need 5 votes in order to be accepted? Does >>it >> only need 1 GTG vote because FUSE packages already exist on most major >> Linux distros? > >A GTG should be ok here. Thank you. Much appreciated. Any takers? Bill
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 what the Cygwin community wants. However I note that this may create the following problem. Packages that depend on FUSE will need to have that dependency satisfied by a number of different *-fuse packages. Perhaps the dependency system in Cygwin is flexible enough to support this (I don’t know). For example I am planning to follow up this submission with SSHFS and FUSEPY submissions. I would like to make these packages depend on a FUSE package, so that we do not end up with a winfsp-sshfs package, a dokan-sshfs package, etc. Even more importantly I would like SSHFS and FUSEPY to build/run out of the box without having to add special logic for winfsp-fuse vs dokan-fuse, etc. >The official fuse window integration is an official request made by >devs on WPDEV. This request is well placed on the top so it is >probably only a question of time before windows do it in the same time >as the Linux subsystem integration. >https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-u >buntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-suppo >rt-in-wsl I am sorry, but having worked for Microsoft this is definitely wishful thinking. If anything Microsoft would likely do it themselves. Heck I might just rejoin them and do it for them ;) >I also would like to point out that WinFSP has absolutely no feedback >of any kind by users and has not been tested on all windows versions. >I think Kernel drivers should at least have some feedback and known as >used in production before choosing to be distributed as cygwin >package. >Unstable kernel drivers can create severity damage in case of BSOD >like windows or user files corruption. > >These analyses are probably severe but for the good of cygwin users, >integrate kernel driver dependence should be well thought before >making the step. Rubbish! I am sorry that you are so upset Liryna that I decided to create my own project instead of continuing to contribute to Dokany. But to go around and spread unsubstantiated rumors is not acceptable. You do not know how many people use WinFsp. To claim that there is no feedback is simply false. There is no feedback that you see, but there is quite some favorable feedback that I have seen including commercial propositions. Furthermore being the number 1 trending project on GitHub (for the C language) certainly shows some favorable feedback. I would strongly argue that WinFsp is stabler and takes file system semantic correctness far more seriously than Dokany. I note that you use my own file system test suites to test your file systems and that Dokany breaks with such basic things like memory mapped files and share access. I could enumerate all of Dokany’s failings, but I will spare you the embarrassment. Bill
Re: [ITP] FUSE 2.8
On 22/07/2016 14:30, Adrien JUND wrote: Hi, Here is Liryna from Dokan-dev community, our project Dokany have the same purpose of Bill project. Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist. I would like to point out that naming WinFSP package "fuse" is not the right way to integrate WinFSP in cygwin. The package is not related to fuse developers or community. It would make the user believe that the package is an official fuse project and I am not sure that’s what Nikratio from libfuse would like. 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... All these packages would install their own libfuse for link compatibility that use their own dependency. Fuse name should be kept for official port by libfuse or by a future integration directly compatible with windows kernels. winfsp-fuse is a reasonable name. dokan-fuse also (IMHO) The official fuse window integration is an official request made by devs on WPDEV. This request is well placed on the top so it is probably only a question of time before windows do it in the same time as the Linux subsystem integration. https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl This seems just a wish for the time being. Also our team leader asked for a fork or for more support in the implementation of it but MS have never supported it. :-( I also would like to point out that WinFSP has absolutely no feedback of any kind by users and has not been tested on all windows versions. I think Kernel drivers should at least have some feedback and known as used in production before choosing to be distributed as cygwin package. Unstable kernel drivers can create severity damage in case of BSOD like windows or user file corruption. These analyses are probably severe but for the good of cygwin users, integrate kernel driver dependence should be well thought before making the step. Thanks, Liryna In general accepting a package is not endorsing its usage or quality. We leave that to upstream responsibility, like it was for libusb. Regards Marco
Re: [ITP] FUSE 2.8
Hi, Here is Liryna from Dokan-dev community, our project Dokany have the same purpose of Bill project. Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist. I would like to point out that naming WinFSP package "fuse" is not the right way to integrate WinFSP in cygwin. The package is not related to fuse developers or community. It would make the user believe that the package is an official fuse project and I am not sure that’s what Nikratio from libfuse would like. 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... All these packages would install their own libfuse for link compatibility that use their own dependency. Fuse name should be kept for official port by libfuse or by a future integration directly compatible with windows kernels. The official fuse window integration is an official request made by devs on WPDEV. This request is well placed on the top so it is probably only a question of time before windows do it in the same time as the Linux subsystem integration. https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl I also would like to point out that WinFSP has absolutely no feedback of any kind by users and has not been tested on all windows versions. I think Kernel drivers should at least have some feedback and known as used in production before choosing to be distributed as cygwin package. Unstable kernel drivers can create severity damage in case of BSOD like windows or user file corruption. These analyses are probably severe but for the good of cygwin users, integrate kernel driver dependence should be well thought before making the step. Thanks, Liryna 2016-07-22 9:59 GMT+02:00 Corinna Vinschen: > 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 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 to “no+body”. > > Done. > >> I also would ask others to chime in regarding this package and >> specifically if it is one they would like to see in Cygwin. >> >> I am also unclear on what the next steps are regarding this package >> submission. Does the package need 5 votes in order to be accepted? Does it >> only need 1 GTG vote because FUSE packages already exist on most major >> Linux distros? > > A GTG should be ok here. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat
Re: [ITP] FUSE 2.8
Hi, Here is Liryna from Dokan-dev community, our project Dokany have the same purpose of Bill project. Like WinFSP, it is able to mount FUSE filesystem on cygwin before WinFSP exist. I would like to point out that naming WinFSP package "fuse" is not the good way to integrate WinFSP in cygwin. The package is not related to fuse developers or community. It would make the user believe that the package is an official fuse project and I am not sure that’s what Nikratio from libfuse would like. 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... All these packages would install their own libfuse for link compatibility that use their own dependency. Fuse name should be kept for official port by libfuse or by a future integration directly compatible with windows kernels. The official fuse window integration is an official request made by devs on WPDEV. This request is well placed on the top so it is probably only a question of time before windows do it in the same time as the Linux subsystem integration. https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13522845-add-fuse-filesystem-in-userspace-support-in-wsl I also would like to point out that WinFSP has absolutely no feedback of any kind by users and has not been tested on all windows versions. I think Kernel drivers should at least have some feedback and known as used in production before choosing to be distributed as cygwin package. Unstable kernel drivers can create severity damage in case of BSOD like windows or user files corruption. These analyses are probably severe but for the good of cygwin users, integrate kernel driver dependence should be well thought before making the step. Thanks, Liryna, 2016-07-22 9:59 GMT+02:00 Corinna Vinschen: > > 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 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 to “no+body”. > > Done. > > > I also would ask others to chime in regarding this package and > > specifically if it is one they would like to see in Cygwin. > > > > I am also unclear on what the next steps are regarding this package > > submission. Does the package need 5 votes in order to be accepted? Does it > > only need 1 GTG vote because FUSE packages already exist on most major > > Linux distros? > > A GTG should be ok here. > > > Thanks, > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat
Re: [ITP] FUSE 2.8
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 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 to “no+body”. Done. > I also would ask others to chime in regarding this package and > specifically if it is one they would like to see in Cygwin. > > I am also unclear on what the next steps are regarding this package > submission. Does the package need 5 votes in order to be accepted? Does it > only need 1 GTG vote because FUSE packages already exist on most major > Linux distros? A GTG should be ok here. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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 to “no+body”. I also would ask others to chime in regarding this package and specifically if it is one they would like to see in Cygwin. I am also unclear on what the next steps are regarding this package submission. Does the package need 5 votes in order to be accepted? Does it only need 1 GTG vote because FUSE packages already exist on most major Linux distros? Thanks. Bill
Re: [ITP] FUSE 2.8
On Jul 19 17:26, Bill Zissimopoulos wrote: > 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: > > billziss@windows:/cygdrive/y$ ls -l > total 12 > -r--r--r-- 1 nodomain+nobody nodomain+nobody 15 Jun 23 23:57 Foo.txt > -- 1 nodomain+nobody nodomain+nobody 15 Jul 15 16:48 > HelloWorld.txt > d- 1 nodomain+nobody nodomain+nobody 0 Jul 15 16:49 opt > > And here are the actual permissions reported to the OS (and Cygwin): > > billziss@windows:/cygdrive/y$ for f in *; do cacls $f /S; done > Y:\Foo.txt > "D:P(A;;0x1f0199;;;S-1-0-65534)(A;;FR;;;S-1-0-65534)(A;;FR;;;WD)" > > Y:\HelloWorld.txt > "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD > )" > > Y:\opt > "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD > )" > > You will note that nodomain+nobody is used for both user and group. Which > my understanding is that it is legal in Windows. [I note however that > Cygwin is able to distinguish between Unknown+User and Unknown+Group.] There's a difference. Unknown+User/Unknown+Group are just unidirectional fakes for SIDs the Windows functions can't resolve at all. There's no way to convert the username "Unknown+User" back to a valid SID since all unknown SIDs are subsumed under Unknown+User with uid -1. OTOH, "nodomain+nobody" has a valid SID, at least in our self-defined realm. So Cygwin gets the same S-1-0-65534 SID for both, user and group. Since it has the same SID, it's the same account. For all practical purposes that should work out fine. You know what to do with the SID on your side, Cygwin knows what to do with the SID on its side, Windows... not so, but since it's the same SID it is the same account from Windows' perspective as well. 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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: billziss@windows:/cygdrive/y$ ls -l total 12 -r--r--r-- 1 nodomain+nobody nodomain+nobody 15 Jun 23 23:57 Foo.txt -- 1 nodomain+nobody nodomain+nobody 15 Jul 15 16:48 HelloWorld.txt d- 1 nodomain+nobody nodomain+nobody 0 Jul 15 16:49 opt And here are the actual permissions reported to the OS (and Cygwin): billziss@windows:/cygdrive/y$ for f in *; do cacls $f /S; done Y:\Foo.txt "D:P(A;;0x1f0199;;;S-1-0-65534)(A;;FR;;;S-1-0-65534)(A;;FR;;;WD)" Y:\HelloWorld.txt "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD )" Y:\opt "D:P(A;;0x1f0198;;;S-1-0-65534)(A;;0x120088;;;S-1-0-65534)(A;;0x120088;;;WD )" You will note that nodomain+nobody is used for both user and group. Which my understanding is that it is legal in Windows. [I note however that Cygwin is able to distinguish between Unknown+User and Unknown+Group.] Let me know what you think. Bill
Re: [ITP] FUSE 2.8
On Jul 18 19:51, Bill Zissimopoulos wrote: > 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 look like a question, much. So, what do > >>you prefer? > >> > >> "WinFSP+nobody" > >> "nodomain+nobody" > >> "no+body" > >> > >>Personally I like the third variation but I'm not religious about it. > > > >My preference is for nodomain+nobody, primarily because the individual > >components “nodomain”, “nobody” describe the lack of domain and username > >when read in isolation (i.e. not in the construction nodomain+nobody). But > >WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna, > >as the Cygwin lead are more qualified than me to choose what fits Cygwin > >best. > > BTW, I now note that no+body is more inline with the existing practice of > "Unknown+User”. I assumed that the parts of the “no+body” construction can > be found in isolation (resulting in a domain of “no” and a user name of > “body”), but perhaps this is not possible. Either way I am happy with > whatever you choose. 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/ Please take a look. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
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 look like a question, much. So, what do >>you prefer? >> >> "WinFSP+nobody" >> "nodomain+nobody" >> "no+body" >> >>Personally I like the third variation but I'm not religious about it. > >My preference is for nodomain+nobody, primarily because the individual >components “nodomain”, “nobody” describe the lack of domain and username >when read in isolation (i.e. not in the construction nodomain+nobody). But >WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna, >as the Cygwin lead are more qualified than me to choose what fits Cygwin >best. BTW, I now note that no+body is more inline with the existing practice of "Unknown+User”. I assumed that the parts of the “no+body” construction can be found in isolation (resulting in a domain of “no” and a user name of “body”), but perhaps this is not possible. Either way I am happy with whatever you choose. Bill
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. >> >> 2. Accept the FUSE cygport package, but require that the package >>downloads >> and installs the WinFsp MSI (perhaps as part of its post install >>process). >> >> 3. Reject this package. >> >> I have currently implemented option (1) but I am happy to change to >>option >> (2). The package files can be found at [CYGFUSE]. The source code for >>the >> package can be found under the opt/cygfuse directory in this repository: >> [WINFSP-GH] > >I'm ok with whatever you guys come up with (baring licensing >requirements). Thanks, Corinna. I am in favor of option #1 and if the package gets blessed I will be happy to maintain it. >Just one comment: > >Bill, you're aware that the code for the "nobody" handling is not yet in >the Cygwin git repo? If your code requires the patch, it won't work >with current Cygwin 2.5.2, nor with any developer snapshot. WinFsp implements the agreed upon mapping (S-1-0-65534 <-> 65534). Cygwin does not implement the mapping yet, which effectively means that 65534 gets mapped to -1 (Unknown+User, Unknown+Group). Here is a mini-session with SSHFS with mapping and not mapping the local user to the remote user. $ ./sshfs -p PORT USER@HOST: Y: USER@HOST's password: $ ls -la /cygdrive/y total 16 dr-xr-xr-x 1 Unknown+User Unknown+Group 0 Jul 15 16:49 . dr-xr-xr-x 1 billziss None 0 Jul 18 12:26 .. -r--r--r-- 1 Unknown+User Unknown+Group 15 Jun 23 23:57 Foo.txt -- 1 Unknown+User Unknown+Group 15 Jul 15 16:48 HelloWorld.txt d- 1 Unknown+User Unknown+Group 0 Jul 15 16:49 opt $ pkill sshfs $ ./sshfs -o idmap=user -p PORT USER@HOST: Y: USER@HOST's password: $ ls -la /cygdrive/y total 16 drwxr-xr-x 1 billziss Unknown+Group 0 Jul 15 16:49 . dr-xr-xr-x 1 billziss None 0 Jul 18 12:27 .. -rw-r--r-- 1 billziss Unknown+Group 15 Jun 23 23:57 Foo.txt -rwx-- 1 billziss Unknown+Group 15 Jul 15 16:48 HelloWorld.txt drwx-- 1 billziss Unknown+Group 0 Jul 15 16:49 opt $ pkill sshfs >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 look like a question, much. So, what do >you prefer? > > "WinFSP+nobody" > "nodomain+nobody" > "no+body" > >Personally I like the third variation but I'm not religious about it. My apologies. I did not understand that you were waiting on an answer from me. My preference is for nodomain+nobody, primarily because the individual components “nodomain”, “nobody” describe the lack of domain and username when read in isolation (i.e. not in the construction nodomain+nobody). But WinFsp does not use these names (only the SID’s/UID’s) and you, Corinna, as the Cygwin lead are more qualified than me to choose what fits Cygwin best. Many thanks! Bill
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] >> >> Which brings me to a large caveat with this package. The package has an >> external dependency on my own open source project called WinFsp >>[WINFSP]. > >libusb0 has similar requirements > >Extract from the setup.ini >--- >message: libusb0 "In order to use libusb0, you must download and run the >LibUSB-Win32 driver installer from: >https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/ >1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe" >- > >similar mDNSResponder and avahi. Great. It is good to know that this is not as large a caveat as I thought it was. >> 2. Accept the FUSE cygport package, but require that the package >>downloads >> and installs the WinFsp MSI (perhaps as part of its post install >>process). > >That will be complicated, I prefer #1 I also prefer #1. Bill
Re: [ITP] FUSE 2.8
On Jul 17 01: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]. > > 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 and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR]. > > FUSE file systems that use this package will expose a file system not just > to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of > Windows apps will be able to access their files). For this to work the > cygfuse.dll in the package needs to interface with a kernel mode > component, which does NOT ship as part of this package. > > Which brings me to a large caveat with this package. The package has an > external dependency on my own open source project called WinFsp [WINFSP]. > WinFsp includes the necessary kernel-mode driver that enables the > FUSE-like functionality on Windows. Unfortunately this driver can only be > built with Microsoft tools. Furthermore it must be signed with an EV > certificate (and going forward Microsoft will soon require that they sign > every kernel mode driver themselves through the sysdev portal). > > For this reason you cannot simply get the source code for the FUSE cygport > and WinFsp and compile everything from scratch. This is not a licensing > issue (all code is AGPLv3), but a tools/signing issue. The alternatives > are: > > 1. Accept the FUSE cygport package as is. Understand that it requires > prior installation of WinFsp in order to properly work. > > 2. Accept the FUSE cygport package, but require that the package downloads > and installs the WinFsp MSI (perhaps as part of its post install process). > > 3. Reject this package. > > I have currently implemented option (1) but I am happy to change to option > (2). The package files can be found at [CYGFUSE]. The source code for the > package can be found under the opt/cygfuse directory in this repository: > [WINFSP-GH] I'm ok with whatever you guys come up with (baring licensing requirements). Just one comment: Bill, you're aware that the code for the "nobody" handling is not yet in the Cygwin git repo? If your code requires the patch, it won't work with current Cygwin 2.5.2, nor with any developer snapshot. 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 look like a question, much. So, what do you prefer? "WinFSP+nobody" "nodomain+nobody" "no+body" Personally I like the third variation but I'm not religious about it. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: [ITP] FUSE 2.8
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]. 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 and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR]. FUSE file systems that use this package will expose a file system not just to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of Windows apps will be able to access their files). For this to work the cygfuse.dll in the package needs to interface with a kernel mode component, which does NOT ship as part of this package. Which brings me to a large caveat with this package. The package has an external dependency on my own open source project called WinFsp [WINFSP]. WinFsp includes the necessary kernel-mode driver that enables the FUSE-like functionality on Windows. Unfortunately this driver can only be built with Microsoft tools. Furthermore it must be signed with an EV certificate (and going forward Microsoft will soon require that they sign every kernel mode driver themselves through the sysdev portal). For this reason you cannot simply get the source code for the FUSE cygport and WinFsp and compile everything from scratch. This is not a licensing issue (all code is AGPLv3), but a tools/signing issue. The alternatives are: 1. Accept the FUSE cygport package as is. Understand that it requires prior installation of WinFsp in order to properly work. libusb0 has similar requirements Extract from the setup.ini --- message: libusb0 "In order to use libusb0, you must download and run the LibUSB-Win32 driver installer from: https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-devel-filter-1.2.6.0.exe; - similar mDNSResponder and avahi. 2. Accept the FUSE cygport package, but require that the package downloads and installs the WinFsp MSI (perhaps as part of its post install process). That will be complicated, I prefer #1 3. Reject this package. I have currently implemented option (1) but I am happy to change to option (2). The package files can be found at [CYGFUSE]. The source code for the package can be found under the opt/cygfuse directory in this repository: [WINFSP-GH] pkill sshfs Comments greatly appreciated. Bill Regards Marco
Re: [ITP] FUSE 2.8
On 17/07/16 02:02, Bill Zissimopoulos wrote: The package has an external dependency on my own open source project called WinFsp [WINFSP]. WinFsp includes the necessary kernel-mode driver that enables the FUSE-like functionality on Windows. Unfortunately this driver can only be built with Microsoft tools. Furthermore it must be signed with an EV certificate (and going forward Microsoft will soon require that they sign every kernel mode driver themselves through the sysdev portal). For this reason you cannot simply get the source code for the FUSE cygport and WinFsp and compile everything from scratch. This is not a licensing issue (all code is AGPLv3), but a tools/signing issue. IIRC, there is already precedent for this sort of thing in the Linux world, as boot loaders need to be signed to work with UFEI Secure Boot - see [1]. Dave. [1] - https://fedoraproject.org/wiki/Secureboot
[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 and FUSEPY to make them run on Cygwin: [SSHFS-PR], [FUSEPY-PR]. FUSE file systems that use this package will expose a file system not just to Cygwin, but to ALL of Windows (i.e. Explorer, cmd.exe and all of Windows apps will be able to access their files). For this to work the cygfuse.dll in the package needs to interface with a kernel mode component, which does NOT ship as part of this package. Which brings me to a large caveat with this package. The package has an external dependency on my own open source project called WinFsp [WINFSP]. WinFsp includes the necessary kernel-mode driver that enables the FUSE-like functionality on Windows. Unfortunately this driver can only be built with Microsoft tools. Furthermore it must be signed with an EV certificate (and going forward Microsoft will soon require that they sign every kernel mode driver themselves through the sysdev portal). For this reason you cannot simply get the source code for the FUSE cygport and WinFsp and compile everything from scratch. This is not a licensing issue (all code is AGPLv3), but a tools/signing issue. The alternatives are: 1. Accept the FUSE cygport package as is. Understand that it requires prior installation of WinFsp in order to properly work. 2. Accept the FUSE cygport package, but require that the package downloads and installs the WinFsp MSI (perhaps as part of its post install process). 3. Reject this package. I have currently implemented option (1) but I am happy to change to option (2). The package files can be found at [CYGFUSE]. The source code for the package can be found under the opt/cygfuse directory in this repository: [WINFSP-GH] The setup.hint file is as follows: category: Utils requires: cygwin pkg-config sdesc: "WinFsp-FUSE compatibility layer" ldesc: "WinFsp-FUSE enables FUSE file systems to be run on Cygwin." The package is generated by the following cygport file: NAME="fuse" VERSION=2.8 RELEASE=3 CATEGORY="Utils" SUMMARY="WinFsp-FUSE compatibility layer" DESCRIPTION="WinFsp-FUSE enables FUSE file systems to be run on Cygwin." HOMEPAGE="http://www.secfs.net/winfsp/; SRC_URI=${CYGPORT_SRC_URI:-"https://github.com/billziss-gh/winfsp/archive/m aster.tar.gz"} SRC_DIR=${CYGPORT_SRC_DIR:-winfsp-master} src_compile() { lndirs cd ${B}/opt/cygfuse make } src_install() { cd ${B}/inc/fuse includeinto fuse doinclude fuse.h doinclude fuse_common.h doinclude fuse_opt.h doinclude winfsp_fuse.h cd ${B}/opt/cygfuse dobin cygfuse-${VERSION}.dll dolib libfuse-${VERSION}.dll.a dosym libfuse-${VERSION}.dll.a /usr/lib/libfuse.dll.a dopkgconfig fuse.pc } RESTRICT="strip postinst-doc" To test the package install it and the WinFsp MSI. Also install glib2 and any build tools you may be missing. Clone my fork of SSHFS from [SSHFS]. Then issue the following commands in the cloned repository. autoreconf -i ./configure make You should now be able to test sshfs with a command line such as: ./sshfs -o idmap=user billziss@macbook-pro: Y: Be sure to issue this command from a non-administrator prompt as Windows has some arcane rules on how drives are assigned. You can now open Windows explorer and browse through drive Y:. When you are done simply issue: pkill sshfs Comments greatly appreciated. Bill [CYGFUSE] https://github.com/billziss-gh/winfsp/releases/tag/v0.14 [FUSE] https://en.wikipedia.org/wiki/Filesystem_in_Userspace [FUSEPY-PR] https://github.com/terencehonles/fusepy/pull/54 [SSHFS] https://github.com/billziss-gh/sshfs [SSHFS-PR] https://github.com/libfuse/sshfs/pull/23 [WINFSP]http://www.secfs.net/winfsp/ [WINFSP-GH] https://github.com/billziss-gh/winfsp