Site navigation

File::createLegalPathName()

General JUCE discussion
#1

This function can cause an assert if the input is empty...

String File::createLegalPathName (const String& original)
{
    String s (original);
    String start;

    if (s[1] == ':') // <- here
    {
       ...

I expect the result would technically not be a legal path, but should it handle this?

On a related note, I've found that (on windows) isAbsolutePath() returns true for "/" (which isn't valid). There doesn't appear to be a 100% reliable function to determine whether or not a given (user provided) String will successfully make it through the File constructor. Unless I'm missing something!

#2

Ta, will avoid that assertion.

Can't see how '/' could be an absolute path on windows though... Do you mean '\' ?

#3

Mmm, when I am working with Windows cmd.exe and Linux consoles at the same time, I always use / in Windows as well, no problem

#4

Sorry, in the code it just uses the 'separator' symbol, which my brain always classes as '/' :)

My point was that the following bit of code...

bool File::isAbsolutePath (StringRef path)
{
    return path.text[0] == separator
           #if JUCE_WINDOWS
            || (path.isNotEmpty() && path.text[1] == ':');
           #else
...

... sees the single slash character in the string and so returns that it is an absolute path - but obviously it isn't, and the File constructor rejects it.

Basically, I'm just trying to find a way to know for sure whether or not a given string will be safe to use in the File constructor :) 

#5

Well..  a path that starts with a backslash is kind of an absolute path, don't you think? Or do we reckon that on Windows only something that starts with a drive letter can count as an absolute path?

#6

It's funny you should say that, as I've been going backwards and forwards about it for a few days - I only even decided to mention it because of the other assert :) obviously a slash at the start means it's not a relative path, therefore it is effectively absolute... But not necessarily fully formed.

It always comes back to needing to be able to satisfy the File class itself. Perhaps moving the constructor checks out into a public static 'isValidPath' function is what is really needed.

#7

But what would 'isValidPath' really mean.. Isn't a partial path also valid if you're planning on using it in getChildFile()?

#8

Well, maybe not isValidPath :) - perhaps isValidFullPath or isFullyFormedAbsolutePath... whatever you would call the checks that the File class itself does to the provided path upon construction.

I.e. the File class has a specific idea about what makes a valid path, (since it asserts if a path doesn't qualify!). That is what I mean by valid path :D

That's really all it comes down to - I just need to be able to guarantee that it is safe to construct a File for a given String (since isAbsolutePath isn't sufficient for that), without having to test manually.

If I'm missing an existing function that does the trick for this, let me know :D

#9

I'm just wondering why I've never needed to do a similar check.. I think that when I've got a user-supplied string that may be dodgy, I generally use File::getCurrentWorkingDirectory().getChildFile (dodgyString), so that it's actually ok to get a partial path.

#10

That makes sense, and I might be able to work with it - but I think we're thinking about different problems.

Using that approach is a means of coping with input - it doesn't actually allow you to validate it, since it will give you a File regardless (and - depending on the input - that File's path could be different at runtime across different machines). I'm in particular trying to validate a specific path, rather than merely cope with it and potentially end up pointing at something different.

#11

Yup. Maybe sketch out the function that you're really looking for, and I can add it if it makes sense!