Build 6821 on CentOS 7.2.1511 folder naming problem

[sudburr]

If I use a “+” in an image name, the resulting image path as displayed by FOG includes the +, but the real directory created uses a < space > .

Image name = “abcd_+_"
Image path = "abcd_+_"
Real directory = "abcd_ _"

Leads to chaining path errors etc.

[george1421]

Well you just hit on a special character issue (which should probably be trapped in the gui and not allowed to exist). Special characters should not be used for image names because they may have a negative impact on the underling file system. The plus in itself is not an issue with the filesystem if escaped correctly. But it might cause an issue from the web gui side.

IMO it’s not necessarily a bug, but an oversight in the code.

[sudburr]

Six of one …

[Tom Elliott]

@sudburr I’ve added a “escapeshellcmd” to the bootmenu that get’s the storage and img information so that characters that could be problematic get escaped. I don’t know if it will work for you scenario.

[Tom Elliott]

I’ve solved this thread as I finally found out what was happening. Wget passing variables turn’s a + into a space, unfortunately.

The good news, I already check for the image object and have really no need to use the wget passed element to choose the file location it needs to go to.

This is now confirmed, found, fixed, tested, and pushed.

[george1421]

@Tom-Elliott I would still have to question is it good practice to allow special characters ("+?#$:@') in the image name/path on disk? While they may add readability for humans, for computers I can just see complaints, even if they are properly escaped.

[Tom Elliott]

@george1421 A + is perfectly fine in any path. Other special characters are perfectly fine as well, so long as they’re properly escaped. I know this is what you’re against, but it does already filter most other special characters, even as much as getting right of other weird special characters.