Message from David Roundy:

>> "get"-ing a repository that contains an upper case file name fails on vfat filesystem
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325693
>
> This is an odd one--I've never seen a bug report like it.

David, what do you think of the attached patch in the Debian bug
report?

peace,

  isaac

I've seen this, and in my case it turned out to be a limiatation of
the Linux VFAT implementation.

Darcs is designed to work well on case-preserving filesystems, whether
case-sensitive (as traditional Unix filesystems) or not (as Mac OS X'
HFS+).  Darcs does not work on filesystems that don't preserve file
case.

If you create an all-caps file on a Linux VFAT filesystem that fits in
the 8+3 format, then Linux doesn't create a ``Long Filename'' (LFN),
but just maps it to an 8+3 filename.  The net effect is that if you do

  touch README
  ls

you will see a file ``readme'' in place of ``README''.

I have no idea if there are any ways to munt a VFAT filesystem to be
case-preserving.  It's also not clear to me whether Darcs can be made
to work on non-case-preserving filesystems.

As a workaround, you can use ``no-pristine-tree'' repositories on your
VFAT filesystems which will almost, but not quite, work around the
problem.

I'm deferring this bug for now, -- but that's only because we don't
have a WONTFIX status.  Feel free to reopen it if you have a workable
idea how to work around the issue.

                                        Juliusz

On Mon, Dec 05, 2005 at 12:02:17AM +0000, Isaac Jones wrote:
> >> "get"-ing a repository that contains an upper case file name fails on vfat filesystem
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325693
> >
> > This is an odd one--I've never seen a bug report like it.
> 
> David, what do you think of the attached patch in the Debian bug
> report?

I wasn't able to find the patch on the bug report, but Juliusz is our local
filesystem expert, so I generally defer to his advice on issues like this.
-- 
David Roundy
http://www.darcs.net

David Roundy <bugs@darcs.net> writes:

> David Roundy <droundy@darcs.net> added the comment:
>
> On Mon, Dec 05, 2005 at 12:02:17AM +0000, Isaac Jones wrote:
>> >> "get"-ing a repository that contains an upper case file name fails on vfat filesystem
>> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325693
>> >
>> > This is an odd one--I've never seen a bug report like it.
>> 
>> David, what do you think of the attached patch in the Debian bug
>> report?
>
> I wasn't able to find the patch on the bug report, but Juliusz is our local
> filesystem expert, so I generally defer to his advice on issues like this.

Ah, sorry.  The patch was on the 'socket' report.

peace,

  isaac

I have an idea how we could work around this.  Once we have a
non-filesystem-based pristine cache (e.g. halfs), we could use that to apply the
patches first to the pristine cache when running get, and then cloneSlurpy or
something to generate the working directory.  It's just one more (of many)
reason why having some sort of database/flat-file pristine cache would be
useful.  Anything to insulate us from the vagaries of the filesystem.

David.

David Roundy <bugs@darcs.net> writes:

> David Roundy <droundy@darcs.net> added the comment:
>
> I have an idea how we could work around this.  Once we have a
> non-filesystem-based pristine cache (e.g. halfs), we could use that to apply the
> patches first to the pristine cache when running get, and then cloneSlurpy or
> something to generate the working directory.  It's just one more (of many)
> reason why having some sort of database/flat-file pristine cache would be
> useful.  Anything to insulate us from the vagaries of the filesystem.

I will continue to push to get Halfs released.  Maybe I can work on it
over the break (next week).

pax

I believe this is resolved-in-unstable when using the new hashed or darcs-2 repo
formats.

That is correct.