Tested on version 3.0.27a to be exact, could not find it in the list. I'm not sure wether this should be in libsmbclient category as this also applies to smbd. $ cd ~/testdir $ mkdir "john \"ripper\" doe" $ touch test.txt $ ls john "ripper" doe/ test.txt the attached program when set to print contents of that dir will output: smb://192.168.1.203/jonas/testdir <DIR> name: . decoded: . <DIR> name: .. decoded: .. <DIR> name: JSD7I4%7EK decoded: JSD7I4~K <FILE> name: test.txt decoded: test.txt "name" is the urlencoded version, "decoded" is the decoded version. As you can see the file name called "john \"ripper\" doe" is called something completely different and when trying to open that directory it will return with errno set to ENOENT. When I browse that share/directory from a Windows client I get the same name (JSD7I4~K) and I cannot enter it.
Created attachment 3023 [details] test program Hard coded IP, username, password and sharename, modify it to suit your needs if you want to try it.
This is a server issue, not libsmbclient. The problem is reproducible from a Windows box.
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx "... Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following: * The following reserved characters: o < (less than) o > (greater than) o : (colon) o " (double quote) o / (forward slash) o \ (backslash) o | (vertical bar or pipe) o ? (question mark) o * (asterisk) ..." So "john \"ripper\" doe" would not be a legal filename.
Created attachment 5410 [details] Proposed patch But should'nd we check if a filename is legal before we try to mangle it? Jeremy, can you please check?
Above patch will make illegal filenames disappear completely to the clients.
patch is for master
Have you tested this against a Windows server ? I'd believe an smbtorture test much more than I'd believe an MSDN doc I'm afraid. Jeremy.
Created attachment 5411 [details] screenshot i guess the docs are more or less an advice not to use them. Explorer may also prevent users from creating files like that. The screenshot shows that those characters *are* alloed on NTFS.
Ok, sorry. I was under the impression that MSDN docs are valid.
Well they're a guide Holger, but only a guide :-). We need to confirm everything they "claim" with torture tests against the latest Windows release :-). Jeremy.
actually while taking a look into the initially reported problem I now think that Holger's patch is actually correct. The files I created on the NTFS volume (hacked on it via ntfs-3g :-) are "view-only" and not accessable in any way. One can not even rename or delete them on a XP machine. Accessing a file called a:foo triggers read trys on a floppy drive and so on. Interesting things happen :-) Finally I think it's perfectly valid to mangle these filenames for non-unix clients. hash2 already acts like this, Holger's patch addresses hash the same way. Jeremy, do you agree?
err, what patch did I look at, that one addesses hash2. Anyway, to hash the filenames seems to be the right thing to do.
Blörn, I was just backtracing what happens when I use the same procedure as the reporter described, and just found it goes into hash2. I did not even knew about hash.
I am not sure how we go on here. As Björn describes in comment #11, those filenames are indeed illegal under windows. One cannot do any file system operation with them, and they lead to unkown effects. Therefore I still think my patch has at least some points. You can create such a filename through linux only, for example smbclient will not allow to create such a filename.
*** Bug 8653 has been marked as a duplicate of this bug. ***