April 6, 201511 yr unRAID OS Version: 6.0-beta14b Description: When creating a user share with certain characters that need escaping, e.g. [inbox], the Samba share name is truncated at the second special character. This can lead to shares being unaccessible, with the final created share taking the Samba name. How to reproduce: Create user shares: [inbox] [inbox]2 [inbox]3 Add a small file to each (a.txt, b.txt, c.txt). Note that the directories turn up correctly on the disk (/mnt/disk1/\[inbox\]) etc Browse via Samba share - and you will see only the file in 3. The share will be named [inbox Expected results: Shares exposed per the created names Actual results: Only visible share is [inbox Which contains c.txt Other information: Didn't test all special characters, but using a $ in the share name had some odd results too. The Shares management page in the web GUI shows the information correctly, it just looks like the Samba share creation isn't correctly escaping the characters.
April 7, 201511 yr Are you sure unRAID is at fault here and not SMB? [ and ] are not valid filename characters for Windows/DOS.
April 7, 201511 yr Author I think so as the leading '[' comes through. I have a bunch of other shares with spaces that work correctly, including lower case characters - which don't follow the 8.3 spec. Example: Movies (3D) I just created this successfully too: Hello+World.Me and it is correctly exposed as that; and works. Although the GUI tried to tell me that the share had been deleted on creation, it did work and it is manageable. Out of interest, this didn't work: the GUI refreshed and nothing at all seemed to happen: <funnyNames/> Yet this did: Movies = cool [edit] Don't get me wrong: I don't see this as anything approaching an optional fix, but called it out as it was odd behaviour. Not sure what else may be under the hood that could be affected.
April 7, 201511 yr I found the following: NTFS file system Legal characters in NTFS include the following: ! [ ] . ; = ( ) Illegal Characters: The following characters are not permitted in Windows file or directory names: / \ : * ? " < > | According to this source, the ']' should be a legal character. What I suspect is happening is that the characters are running through the HTML character handling and (possibly) BASH script and/or shell character processing. Any of the special characters may have a special significant to the interpreter and get strip out (or even ignore everything that follows the character.) It is always best to avoid using any of the special characters unless one is absolutely certain that they will work in any environment. (Remember that the # character is used in most Linux shells scripts to indicate that everything that follows is a comment!) If you look at the characters mentioned and then look at your keyboard, you will find that are a substantial number of characters that are not defined as either 'legal' of 'illegal'. What happens if one decides to use one or more of them? It could be that the name would be fine in one environment and not in some other one!
May 1, 201511 yr How big of an issue is this really? Just trying to understand if this is just a minor annoyance or if anyone has an extreme example of where this is debilitating to their needs.
May 3, 201511 yr Author Per my comment above, for me its not a biggie at all. Don't get me wrong: I don't see this as anything approaching an optional fix, but called it out as it was odd behaviour. Not sure what else may be under the hood that could be affected. Having written software though I understand the desire to know when something isn't quite right. Who knows what else may be linked to it. More than happy for this to be a "won't fix (for now)" if that is the call.
May 5, 201511 yr Per my comment above, for me its not a biggie at all. Don't get me wrong: I don't see this as anything approaching an optional fix, but called it out as it was odd behaviour. Not sure what else may be under the hood that could be affected. Having written software though I understand the desire to know when something isn't quite right. Who knows what else may be linked to it. More than happy for this to be a "won't fix (for now)" if that is the call. I think we'd have to look at this after the release of 6.0. There are bigger fish to fry for now. Thanks for your understanding!
Archived
This topic is now archived and is closed to further replies.