Windows client fails to download file with device name

(Incidentally, I don't think a "fix" is necessary here, documenting the behaviour and leaving as is would be IMHO enough, I'm just actively hunting edge cases).

Ah, yes, I'm not sure what to do here as windows will not let you create a file with those names.
I'll mark it as confirmed so the windows and syncdaemon hackers will take a look at it.
Also, the error recorded on the log sounds weird. It should be improved to tell what's really happening. It's just that I don't understand what's happening, the error message from windows when I try to create a file with those names says: "The specified device name is invliad.". That's as bad as what we are saying in the log. Do you have more information, Jon?

Thanks again for your report.

The Windows file-system uses them as device names, comparable to the special files that are mostly in /dev/ in *nix (indeed, NUL for example is pretty much the same as /dev/null). Now, MS-DOS didn't have a tree-structure directory until version 2.0 in 1983 and in 1.0 there were just files with names in a single namespace per drive. For compatibility with this, even today you can't create a NUL anywhere - it's like trying to create a /dev/null in *nix! Since NUL is a device, the error message can be the confusing "the specified device name is invalid". (Creating D:.txt would cause the same error were it not for the fact that : isn't allowed in filenames will kick in first).

Where it can easily hit, is if a program produces some small names for its own files. It's not that likely to be something someone is using U1 to share, but it could confuse them if they do.

There's not much that can be done about it, bar warning the user with a better explanation than silent behaviour from the UI and the log record that is, as you say, only understandable if you already know this feature of Windows.

http://support.microsoft.com/kb/74496 is a relevant article from MS, though doesn't include all relevant names (it doesn't mention COM4, though it is affected and does mention CLOCK$ which works fine these days - alas I don't know which version it started being acceptable with).

Ugh?! Nice, I though I managed to work around this issue. Let me explain what is going on:
Current work around explanation:

It is indeed true that the filenames you mentioned cannot be written on windows, but that is just a partial truth. On Ubuntu One we try to be as smart as possible (some times too smart) and we use the literal path prefix (\\?\ or \\\\?\\ if you have to scape \)to work around a number of filename issues, one of them being this.

Windows is an interesting OS (to call is something), so lets take a look on what happens:

1- Using COM1 no extension no literal path prefix:

path = 'C:\\Users\\Mandel\\COM1'

with open(path, 'w') as fd:
    fd.write('hello')

[Errno 2] Not such file or directory.

2- Using COM1 with extension no literal path prefix:

path = 'C:\\Users\\Mandel\\COM1.txt'

with open(path, 'w') as fd:
    fd.write('hello')

[Errno 2] Not such file or directory.

****** Here comes the interesting stuff which is the way it is implemented in Ubuntu One *******

3- Using COM1 no extension AND literal path prefix:

path = '\\\\?\\C:\\Users\\Mandel\\COM1.txt'

with open(path, 'w') as fd:
    fd.write('hello')

works \o/ but windows is weird, if you try to open the file using the explorer it fails :(. Yet the following works:

with open(path, 'r') as fd:
    print fd.readlines()

>> ['hello']

and os.listdir (list the dirs) does show the file yet os.path.abspath (the method used to get the abspath of a file) returns \\.\COM7 (there is the bug by the way ;-) /me feels smart)

4. Using COM7 with extension AND literal path prefix:

Same as 3

Summary:

There is indeed a bug, but not in the syncing of the file but in the local scan which breaks because asbpath breaks on windows. The reason for that is hidden in the standar lib of python (I have already sent a number of patches to python3 itself to fix this funny issues).

I think I can make Ubuntu One not only to sync the file (which already happend) and to scan it correctly without going crazy like it does in you case which solves your problems and makes dropbos look bad ;-)

I forgot to mention, I can fix it but I need time because I'm in the middle of fighting with Mac OS X :)