On Fri, Nov 27, 2009 at 04:53:26PM +0000, Fergus wrote: >Fergus wrote: > >>> I am having ongoing problems with file processing using [1.7] > >>> with W7 on FAT32. > >Corinna wrote: > >> IT'S ALL MY FAULT. > >> I dislike FAT32 a lot, so I usually never test on it. > > > I just uploaded a new Cygwin 1.7 test release, 1.7.0-67. > >And it has cleared up the glitch in the context I described. > >THANK YOU THANK YOU THANK YOU. > >I hate NTFS as much as you dislike FAT32, I'm sure. Possibly more. For >all its disadvantages (dangers? not in my world) I'll stick with FAT32 >and its manageable permissions and test things on [1.7] as best I can >for as long as I can and as long as [1.7] recognises FAT32 as a viable >platform to be supported. > >Which by implication of your transition 1.7.0-66 -> 67, it does? Which >therefore in turn raises this: > >FAT32 + [1.7] + XWin stopped being a viable combination after 1.7.60 for >the reasons you describe at >http://cygwin.com/ml/cygwin-xfree/2009-11/msg00081.html (incidentally I >find the -nolock switch has no useful effect). > >So a FAT32 user is stuck with >EITHER >reverting to 1.7.0-60 if using XWin >OR >using 1.7.0-curr but without XWin. > >Is there any likelihood that Cygwin chiefs would reconsider the decision >leading to this restriction so that the up-to-date combination >FAT32 + [1.7.0-curr] + Xwin >remained a possibility?
The above referenced URL says: "As for X, it should have a fallback method if the /tmp filesystem doesn't support hardlinks." That seems pretty clear to me. You should be taking this up with the X maintainers rather than asking for a hacky cygwin DLL fix. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
