Re: compromise for case-challenged file systems?

[Eric Blake]

[adding gnulib]

On 05/17/2015 03:55 AM, Pádraig Brady wrote:
> On 17/05/15 00:34, Jim Meyering wrote:
>> I noticed that since the addition of the file,
>> tests/tail-2/F-vs-rename.sh, one can no longer
>> clone coreutils onto a case-challenged file system,
>> because there is also a file in that directory whose
>> name differs only in the case of the "f":
>>
>>   tests/tail-2/f-vs-rename.sh
>>
>> What do you think about fixing this?
>> Since it's easy to avoid, you may want to write a
>> syntax-check rule using something like this:
>>
>>   $ git ls-files|tr '[:upper:]' '[:lower:]'|sort|uniq -d
>>   tests/tail-2/f-vs-rename.sh
>>
>> Actual consequence?
>> When I clone onto an hfs file system (OS/X), the initial
>> is shown as unclean, with tests/tail-2/F-vs-rename.sh
>> being shown as modified (with the differences to transform
>> it to the contents of the lower-case-named file).
> 
> Yes it's definitely worth avoiding that issue.
> Proposed patch attached.

In fact, I think such a patch would be good in gnulib's maint.mk for all
projects to benefit from, and that it could additionally check for other
problematic characters such as ':' which cannot be cloned onto FAT
systems, or even that file names within the project do not exceed the
99-byte limit of older tar archive constraints.  That is, ensuring that
all file names within a project are portable is a good goal for making
the project more accessible.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature