Hi all,
I have found an issue where a carriage return character (\r
) is added to some file paths when using File::getRelativePathFrom()
. From my sample of about 4 files (not exactly statistically significant) this seems to be a file without an extension.
What I’m doing is this…
ZipFile::Builder zipBuilder;
Array<File> myFiles;
someDirectory.findChildFiles (myFiles, File::findFiles, true, "*");
//add files
for (int i = 0; i < myFiles.size(); i++)
{
String path = myFiles[i].getRelativePathFrom (someDirectory);
zipBuilder.addFile (myFiles[i], 0, path);
}
and one of the files in the directory is a Icon
file which can be found in an Ableton Live project folder (which is what we are zipping). The path of this file (when inspected) ends in a \r
character.
I have found that then in attempting to then uncompress the zip file on Windows, this causes a failure as when we get to ZipFile::uncompressEntry
, the entryPath
in that function contains the return character and this later causes the the entry to be unreadable and process fails.
I am not sure if this is something I am doing wrong in approaching this, or if it is a bug for certain file types (do we ever want a \r
at the end of a file path?).
As a quick fix we added a small change to JUCE in ZipFile::uncompressEntry
just after the entryPath
is calculated on line 407:
if (entryPath.endsWith ("\r"))
entryPath = entryPath.dropLastCharacters (1);
I know we also should deal with the problem at source, but it seems to me this is (probably?) a harmless change to the ZipFile
class to make it more robust to issues with the entries.
Let me know your thoughts,
Adam
p.s. - Final bit of context: the zip file was made on a Mac and attempted to be decompressed on Windows