I’m not sure I like the decision that is being made in this function (where ‘the only common bit is the root’); I think that as long as the files are indeed on the same drive, it should always return a relative path.
Example: This behaves as expected…
File a(T("C:/Test1/Sub"));
File b(T("C:/Test1/file.txt"));
String s = b.getRelativePathFrom(a);
// s == "..\file.txt"
This, on the other hand, produces unsatisfactory results:
File a(T("C:/Test1/Sub"));
File b(T("C:/Test2/file.txt"));
String s = b.getRelativePathFrom(a);
// expected s == "..\..\Test2\file.txt"
// recieved s == "C:\Test2\file.txt"
I’m making a project builder to generate makefiles/VCProjects/etc … part of that is building a list of files and using paths relative to a specified project folder. Naturally it is designed to be executed on the machine which the project is used on, but i was unsettled to see that a bunch of files had literal paths when there was really no reason to.
Basically, with the current function definition, if a file is on the same volume, yet the lowest directory is different, it will not return a relative path. I just can’t understand why that would be considered an acceptable behaviour .
To illustrate, lets say a user has ticked a setting in a juce app to store links to files as ‘relative’; they know that their ‘project’ file is on the same drive as these files; they are learned enough to understand the concept of relative links and are comfortable with the arrangement.
Now consider that, for some reason, they need to move the files (either to a subfolder on the same drive, or onto a different drive). They take care to ensure that the folders containing projects and linked files maintain their relationship in the drive’s folder structure.
Why should they not expect such a procedure to work successfully?
