[PATCH] clone on Windows: abort on reserved filenames (1st update)

Adrian Buehlmann adrian at cadifra.com
Wed Jun 11 22:32:08 UTC 2008


On 11.06.2008 22:08, Mads Kiilerich wrote:
> Adrian Buehlmann wrote, On 06/11/2008 05:25 PM:
>>> +_reserved_filenames = '''CON PRN AUX NUL
>>> +    COM1 COM2 COM3 COM4 COM5 COM6 COM7 COM8 COM9
>>> +    LPT1 LPT2 LPT3 LPT4 LPT5 LPT6 LPT7 LPT8 LPT9'''.split()
>>> +def validpathname(path):
>>> +    for n in path.split('/'):
>>> +        if n.upper() in _reserved_filenames:
>>> +            return False
>>> +    return True
>>>     
> 
> Do you have a reference to the source for _reserved_filenames?

http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

> http://swarajk1.blogspot.com/2007/12/invalid-file-name-list-can-you-do-it.html 
> hints that there could be other. And 
> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html hints that 
> they are invalid even with an extension.

Hmm. I'm not sure on this. The above link talks about "avoiding" them (e.g. NUL.txt).

> And how about invalid characters? And trailing spaces and dots. And 
> MAX_PATH.

For example ":" and other chars are already encoded. See util._buildencodefun,
which also encodes uppercase chars ("HELLO" -> "h_e_l_l_o").

MAX_PATH is an entirely different (unsolved) problem, which I do not
intend to try to tackle with this patch.

> Existing (tracked or untracked) file with different casing could also be 
> said to create invalid path names dynamically.

Not sure what you mean here.

The validation I'm trying to insert with this patch happens during
the transfer phase of the repo data, on the receiving end.

Case folding collisions during the update of the working dir is a later
phase (I *think* there are already some checks in the code for that).

> On Mac there is also unicode normalization.

The code I was trying to write was intended to be effective on Windows
only (I intend to resend a fixed version).

> Perhaps it would be better just to try to create the file, and if it 
> fails then give a nice message.

That's what the current code already seems to try to do. And that seems
not to work (it hangs forever for the aux file case).

Also, some of these special names are devices on Windows. Trying to write
to them will probably work for some, but not reading back (e.g. NUL).

The thing is that the receiving end of a pull sitting on Windows should
probably better do some basic validation of the input data it reads from
the wire. For example, treat it like a user trying to enter "AUX" as a
file name for storing data. The sending end rightfully does not care what
the OS on the receiving side is.

In any case, validpathname() can sure be expanded. But detecting those
obvious reserved names would already be an good improvement over the current
situation. And this can be done without touching the repository layout.
Having a directory called "aux" originating from unix is not such an
extremely rare case.

At least I don't pretend to cover every other odd case with this patch.




More information about the Mercurial-devel mailing list