Date: Fri, 27 Nov 2009 12:38:31 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem [1.7]: Inconsistent and wrong results from e.g. ls and  md5sum
Message-ID: <20091127173831.GA4230@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4B100406 DOT 50906 AT bonhard DOT uklinux DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B100406.50906@bonhard.uklinux.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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