bfiles filename encoding

[Greg Ward]

On Mon, Jun 7, 2010 at 9:52 AM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>> So if we reuse fncache in bfiles, either by copying or refactoring,
>> then bfiles will inherit those two bugs.
>
> Windows Vista and Windows 7 explorer strip leading spaces from filenames
> (see issue1713) when copying trees.
>
> I have never looked at bfiles so far, but I assume bfiles *is* already
> affected by that, or do you already encode leading spaces in filenames?
>
> (I'm a bit puzzled by the term "inheriting". How can you inherit
> something you already have?)

Err, yes, good point.  Currently bfiles does *no* filename encoding
whatsoever.  So if you put your central store on Windows, you can't
have big files "foo" and "Foo", you can't have "aux", you can't have "
foo", and you can't have
"really/long/path/that/blows/windows/tiny/little/brain".  And if you
put your central store on OS X, having a big file ".DS_Store" would be
risky.

Reusing fncache would fix several of those bugs, but not all of them.
That's really what I was getting at: fncache is better than bfiles'
status quo, but not perfect.

Greg