I came across this issue couple of weeks back and can be generated on 1.39, 1.45 and 1.46(released version, didn’t try it on the svn version)
If I created a two file object
if (file1.operator== (file2)) // this condition fails, although physical they are same file
if (file1.operator!= (file2)) // this condition fails, although physical they are same file
I do understand, that in the documentation for these methods you mention
But don’t you think, these methods would be better served if they check if both the file objects are of the same file, rather than checking the file path.
Well, if you’re feeding it crazy paths like that, I’m not surprised that you’re getting strange results! I think a sensible change might be to make sure the File class corrects any double-slashes when the it first gets the path, rather than to change the comparison code…
I know it was a little crazy, but the actually the path was generated internally and due to some unavoidable reason extra separators were added.
I did what you have suggested, Wrote a method for removing excessive file separator and it worked out well.
void FormatFilePath(juce::String & filePath)
juce::String tempFilePath = filePath;
juce::String stringToReturn = juce::String::empty;
int stringLength = tempFilePath.length();
int counter = 0;
while(counter < stringLength)
juce::String pathSeparatedBySeparator = tempFilePath.upToFirstOccurrenceOf(juce::File::separatorString,true,true);
counter = counter + pathSeparatedBySeparator.length();
tempFilePath = tempFilePath.substring (pathSeparatedBySeparator.length());
juce::String chars = tempFilePath.substring(0,1);
tempFilePath = tempFilePath.substring (1);
chars = tempFilePath.substring(0,1);
filePath = stringToReturn;
umm… why not just:
while (name.contains (T("//")))
name = name.replace (T("//"), T("/"));
You are the man, but don’t forget to use juce fileseparatorString instead of “/”
Actually you would have to make a check for both fileSeparatorString and also “/”.
well, yes, I was paraphrasing a bit there!
Anyone know what the “official” view is about double-slashes in file paths? If the OSes consider it legal for a path to contain them, then I should probably make the File class strip them out…
Am not a expert on it, but tried few tricks on my mac. I have an application which ejects disc from disk drives.
I gave it these path “/volumes//icfai”, “/volumes///icfai” and also “//volumes/////icfai”
the app uses cocoa and was able to eject it, so was the finder able to find it when i did “command + shift + g”.
It worked on the terminal too.
although the results on pc were confusing
My windows version of ejecting application worked.(uses win32)
when i tried to open the destination location from run, it allowed multiple slashes but the explorer didn’t allow it. :twisted:
You can safely put the code in for mac but on pc am not sure