File \ Bug?


#1

I have a filename called

“ssc pmoore bmw up\by 01” if I use this along with the absolute path in a File constructor, JUCE replaces the \ with a /

From there my existsAsFile() check fails.

Can Juce be smarter about whether the passed in absolute path is a windows path or not?


#2

Hmm, good point, and quite a tricky problem! I could certainly stop it treating the backslash as a file separator, but that would break cross-platform code that uses the slashes interchangeably… Not sure whether it’s best to change it or leave it!


#3

Yea, certainly don’t want to break anyone…

How about checking for \\ or ?:\ @ the start of the absolute url(for server share and a drive letter), its a win path. Or alternatively if the absolute path starts with / would it be a unix path?


#4

Possibly… But if you’re giving it a partial filename, there’s no way of knowing what they meant.

I suppose one approach might be to make it less tolerant, but to throw an assertion if a file has the opposite type of character in it. That would cause a small number of false alarms for files that have silly names, but would catch people relying on the file class to replace the slashes for them…


#5

I’ve run into this problem recently. It is a bug, because backslashes are legal in Mac and linux filenames. The Finder lets you type them in no problem, and of course so do the POSIX APIs and the shell. Some software will even turn slashes into backslashes when coming up for a filename for some object with a slash in it.

But it would also assert on exactly the cases we’re trying to fix.

Look at the original poster’s question. Let’s say he passed in “~/ssc pmoore bmw up\by 01” instead of just “ssc pmoore bmw up\by 01”. That’s perfectly valid and reasonable, and he’s obviously expecting to find a file named “ssc pmoore bmw up\by 01” in his home directory, and doesn’t expect or want an assertion.

Well, apps that rely on the existing functionality are broken either way; apps that don’t are only broken (in that there are user files they can’t access) because of juce.

My suggestion would be to fix it, but maybe add some compile-time flag, runtime call, and/or extra parameter to the File methods to retain the old behavior.


#6

Thanks, I’ll have a think about that.


#7

Add a code like this, and you’re probably done:

struct ExactFilename
{
    /** Initial string given */
    String path;
    ExactFilename(const String & path) : path(path){}
};

class File
[...]
{
    /** Construct a file whose path is exactly what is given. 
         Any cross platform compatibility checking/fixing is disabled in that case. 
         That means that you can probably open a file "/tmp/something\with\backslash.txt" on a POSIX system.
         However, if such a path is hardcoded in your code, this is very likely to break when porting to other platforms */
    explicit File(ExactFilename & filename);

    /** Get the child file whose path is exactly what is given. 
         Any cross platform compatibility checking/fixing is disabled in that case. 
         That means that you can probably open a file "./something\with\backslash.txt" on a POSIX system. */
    File getChildFile(ExactFilename & filename);
[...]

#8

I’ve already added some code to allow backslashes. I’ve got an assertion in there, but it’s only triggered if you have an absolute path with no forward-slashes, so it’s unlikely it’ll ever be triggered unless someone actually feeds it a complete windows-style pathname.