[BUG] 0.14 bzr add --dry-run: bzrlib.errors.InvalidEntryName: Invalid entry name: '\

[John Arbash Meinel]

Jari Aalto wrote:
> I happened to come accross a project that included a suspicous file names:
> 
>     $ ls -la
>     total 16
>     drwxr-sr-x 3 root src 176 2007-01-27 09:26 .
>     drwxr-sr-x 5 root src 120 2007-01-27 09:26 ..
>     -rw-r--r-- 1 root src  14 2007-01-27 09:26 '\
>     -rw-r--r-- 1 root src  47 2007-01-27 09:26 Maelstrom Sound
>     drwxr-sr-x 6 root src 240 2007-01-27 09:26 .svn
>     -rw-r--r-- 1 root src  89 2007-01-27 09:26  .tif
>     -rw-r--r-- 1 root src  40 2007-01-27 09:26 ".tif
> 

This isn't because of '--dry-run'. This is because we don't let you add
a file with '\' in it, but we do it rather late with an 'assert' rather
than sanitizing it earlier.

We've talked about reducing that restriction. We don't allow '/' in
filenames for obvious reasons, at that time we also disallowed '\'. Part
of that was because we weren't sanitizing paths yet (on win32 we need to
convert '\' => '/')

At this point, I'm pretty confident that any '\' in a filename is simply
because it actually exists there on a non win32 platform.

I don't think our data structures would have a terrible time with '\' in
a filename, though I can see it getting really messed up on win32 (where
we translate '\' => '/' in a lot of places).

So:

1) At a minimum this should have a better error message.
2) We can look at supporting '\' in filenames. An initial guess would be
to just remove the assert, but I have the feeling it is going to break
other things later on. We also need to figure out how to make it clear
why it is broken on win32, and how they can fix it. We have a similar
need for symlinks (see the recent bug where we just fail because 'os'
does not have the 'symlink' function).

John
=:->