support filenames like C:\FOO.TXT

[David Allouche]

bzr init foo ;cd foo
touch 'C:\FOO.TXT' ; bzr add
<traceback>
InvalidEntryName: Invalid entry name: C:\FOO.TXT

Such a file name can be found in the unixodbc CVS repository:
:pserver:<email address hidden>:/cvsroot/unixodbc unixODBC
That is requested for a VCS import in Launchpad:
https://launchpad.net/products/unixodbc/main

CVS supports such file names fine (at least on Linux). This import cannot be completed until bzr supports them as well.

[John A Meinel (jameinel)]

The code in question is in bzrlib/inventory.py line 283.

It is trying to trap someone creating an inventory entry that accidentally has a path component as part of its name. Specifically, it is doing:

if '/' in name or '\\' in name:
  raise InvalidEntryName(name=name)

Now, by this point in the internals of bzr, the path should have been normalized, such that all '\' in the original full path have become '/' internally on Windows.

So we could possibly just change the line to read:
if '/' in name:
  raise InvalidEntryName(name=name)

Now, on Windows, if we ever tried to checkout this tree, I would expect one of the abspath functions to change the '\' into a '/', and things could get pretty messy.

However, this particular code path is reached every time we read an inventory, so we could abstract it into a function, and then on Windows, if we get a 'name' element that includes a '\', we can raise a nice error, which says that filenames with '\' are not supported on Windows.

And then on Linux, we skip that part of the check.

This becomes just one more incompatibility between Linux checkins and Windows checkouts.

Windows doesn't allow all sorts of characters anyway, so we probably should have something like that in place. To handle all of the other bogus windows chars (<>":\/) are the ones I know about off hand.I'm always looking it up, though, I really should bookmark it.

If someone needs '\' support, it should be pretty straightforward to add it.
Also, if we wanted to be really nice, we could degrade the comment to a warning if not on Windows. So people will know that they have a tree that is invalid on Win.

However, this would be the wrong place to do the warning, because it would be encountered every time the Inventory is being read, whether or not the user is doing anything active on that file.

So I would recommend the warning be easy to generate, and have it as part of 'smart_add_tree()', and other such places.

[John A Meinel (jameinel)]

It is arguable that this should be a sanitation by the importer. We don't accept non-unicode paths, we can arguably not accept '\' in paths.

It is possible to fix, and it is also possible for us to only emit a warning, rather than disallowing the path.

For now, marking this as a wishlist.

[Michael Hudson-Doyle (mwhudson)]

I've just had to disappoint a user because of this (the moodle CVS repository had a file called \ in it briefly).

I can see how it's all a horrible mess, but I don't like disappointing users...

[Martin Pool (mbp)]

On 5/25/07, Michael Hudson <email address hidden> wrote:
> I've just had to disappoint a user because of this (the moodle CVS
> repository had a file called \ in it briefly).
>
> I can see how it's all a horrible mess, but I don't like disappointing
> users...

Maybe the importer should remap the filenames... ?

--
Martin

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> On 5/25/07, Michael Hudson <email address hidden> wrote:
>> I've just had to disappoint a user because of this (the moodle CVS
>> repository had a file called \ in it briefly).
>>
>> I can see how it's all a horrible mess, but I don't like disappointing
>> users...
>
> Maybe the importer should remap the filenames... ?

Or you could import only the history after the bad name? (Remapping
would be technically feasible, but then you risk the remapped name being
the same as another name.)

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVu7W0F+nu1YWqI0RAhmGAJ0Za7v+i899C9SSe7DdmmDrCt5ULACZAcgX
WYlm6SNuWxI0K1YX5qt6+lI=
=O8sm
-----END PGP SIGNATURE-----

[Brian de Alwis (slyguy)]

I've just been bitten by this too while trying to convert a git repository (originally a CVS repository) to a bzr repository.

Does the inventory need to enforce this? I'd prefer John's suggestion of emitting a warning.

And isn't this really a problem when creating a working-tree. This restriction would be annoying if I was using a (fictional) file system with no reserved characters?