Filelist Download Failure From Specific Usernames

[Jason Stevens]

There is an issue with DC++ when a user chooses a nickname that happens to be a Windows Reserved Keyword. For example, if a user chooses a nickname from the following list:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 (Reference: http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words)

a Windows user trying to download the filelist from a user with one of these nicks will fail because the filename is in the format of *nick*.xml.bz2 (ex. "aux.xml.bz2"), which is disallowed under Windows. When DC++ attempts to write the remote user's filelist to disk, the download will hang because Windows blocks the writing of this file to disk. There is no error message displayed to the user during this process and the reasons for the download to hang are not clearly apparent. The person that is using this nick will have no issues, because their filelist is named files.xml.bz2 which is allowed.

Ideally, the above list would be disallowed as a username so that Windows users can download their filelists. Other clients would need to adopt this blacklist as well to be good net citizens towards Windows users.

[Jason Stevens (jason89s)]

Alternatively, the filelist could be renamed to avoid conflicting with these keywords by appending/prepending additional characters to the filename ex: dc_nickname.xml.bz2

[poy (poy)]

are you using an old version of DC++? recent ones always append a unique identifier to the name of the file list.

[eMTee (realprogger)]

Whatever you append to "nul." (mind the dot) it will be discarded. And getting filelist from user "nul" indeed doesn't work. It throws a couple of misleading messages in the transferview , the download fails and the item doesn't disappear from the transferview at all.

Strange because we have a function to fix filenames to save (e.g. for hublists) and IIRC the WIN32 part of that function checks for these reserved words. It doesn't seem to be used in the filelist name formatting though.
Asterisks, ?, <>, etc.. in the nick probably cause the same problem.

There's two problems here. The error handling of the errors during any the save of any filelist and the file name formatting itself to avoid the reported error.

[poy (poy)]

ah, because we use "nick.CID.ext" so the filename is only "nick". let's just use "nick-CID.ext" then? should fix it.

[eMTee (realprogger)]

Well, that wouldn't save from other badchars I listed...
Let's use Util::cleanPathChars with implementing "@todo Check for invalid names such as nul and aux... " so we put a hyphen or an underscore or even another dot _before_ these reserved words...

[Crise / MW (markuwil)]

You want to avoid prepending a dot because that is a typical notation for a hidden file on some systems, so it can cause all manner of problems if it ends in the right place on the path.

[eMTee (realprogger)]

True, but again, I am talking about improving code specific to WIN32 and it won't be a problem there. But any of the other options are equally fine, except that dot would make the resulting filename differ (visually) the least from the original "nick.CID.ext" structure.

[Crise / MW (markuwil)]

Is file name/path validation ever truly windows specifc. If the functions are currently only implemented and/or used on windows then that is an oversight considering there is an open bug regarding multiplatform compatibility (yes the function bodies may need to be different for other platforms, but things like resulting downloaded filelist names should be the same for all). So lets not make choices that will cause complications regarding that bug if it can be avoided.

[eMTee (realprogger)]

Indeed, I recommend the less complicated choice. The code is already divided there and if you check what part I am talking about you'll see you can't make it universal even if DC++ goes multiplatform sometime.

[poy (poy)]

note: fixing bug 238482 will also fix this one. :)