Move file : invalide folder path

[un_pogaz]

I wanted to move some files into a folder and since I'm under windows, I used the anti-slash '\' >> "Error, invalid path" >> replaced it by '/' >> OK

Ah, a little parse/replace is missing

[KevinH]

All epub paths are bookpaths from the epub root so these should only use "/" as all hrefs do on all platforms.

Checked the actual code and I am happy that it handles things and only lets valid bookpaths through and \ is not a valid url or href character so I think the code does what it needs to here:

SelectFolder select_folder(group, m_Book, this);

    // Get the destination folder from the user
    if (select_folder.exec() != QDialog::Accepted) {
        return;
    }

    QString folder_path = select_folder.GetFolder();
    // Make sure folder_path is valid if abort
    bool valid_path = folder_path.indexOf("..") == -1;
    valid_path = valid_path && folder_path.indexOf("\\") == -1;
    valid_path = valid_path && !folder_path.startsWith("/");
    valid_path = valid_path && !folder_path.startsWith("./");
    valid_path = valid_path && !folder_path.startsWith(".");
    valid_path = valid_path && folder_path.indexOf("/.") == -1;
    valid_path = valid_path && !folder_path.startsWith("META-INF");
    valid_path = valid_path && folder_path.indexOf("META-INF") == -1;
    
    if (!valid_path) {
        Utility::DisplayStdErrorDialog(
	    tr("Destination Folder has invalid path \"%1\"").arg(folder_path));
	return;  
    }

If your destination already existed you would see its bookpath in the SelectFolder dialog and can see what types of paths it wants. The BookBrowser is not a generic File browser and as such uses / as its folder separator.

[un_pogaz]

Ok, this is an invalid character, but as is the folder separation character in Windows, applying a simple replace '\' to '/' before testing and moving, could be handy.
That's what I meant.

I know that Windows is inferior in this usage, but since it is a folder/file path, most programs (see languages) consider both characters as equivalent, probably thanks to a small and discreet character replacement.
This is not the case with Sigil, which is "too" strict.

[KevinH]

Yes, we could do that to help some users who are not distinguishing internal epub paths from external OS file paths.

But then I would worry that those same people may start using the wrong folder separator in hrefs and src attributes and epub root relative paths throughout css, opf, xhtml, ncx, etc. Also because BookBrowser is not meant to be a FileBrowser that change may confuse things even more.

So Sigil when dealing with paths internal to the epub tries to uniformly use the forward slash just like Qt and Python in this regard. At least that was the design idea.

Yes, it should be an easy change to make, I am just not sure it is for the best. But I am no Windows user, so perhaps others will weigh in on if this will serve to just confuse users or not.

[Doitsu]

Originally Posted by KevinH

But I am no Windows user, so perhaps others will weigh in on if this will serve to just confuse users or not.

1. Windows supports slashes in command prompt/Explorer windows since at least Windows 7. For example, users can enter both:

cd c:/Windows

and

cd c:\Windows

2. Slashes are the default path separators in at least two of the supported operating systems.

3. Users should never have to manually enter paths, since Sigil will automatically suggest the right location(s), when users click the Folders drop-down button.

[DiapDealer]

I'm in favor of leaving it the way it is. The tooltip path shows the forward slash. Book Browser shows the forward slash (if the preference to show the full bookpath is turned on). And the Move dialog itself shows the forward slash whenever selecting existing folders to move resources to. Changing it just to let Windows users continue to make the same mistake over and over (with no notice) makes little sense to me. Make the mistake once, learn what's expected and move on. It's a non-issue in my opinion.

[DiapDealer]

4) Users seeking to alter the internal structure of an epub are unlikely to be tripped up by the forward slash url-path requirement.

[un_pogaz]

Originally Posted by DiapDealer

I'm in favor of leaving it the way it is. The tooltip path shows the forward slash. Book Browser shows the forward slash (if the preference to show the full bookpath is turned on). And the Move dialog itself shows the forward slash whenever selecting existing folders to move resources to. Changing it just to let Windows users continue to make the same mistake over and over (with no notice) makes little sense to me. Make the mistake once, learn what's expected and move on. It's a non-issue in my opinion.

WHAT ??!!
Why is it a mistake to use the default folder separator of your operating system ???
I'm not talking about how it was saved or displayed, just the tolerance of Input Text.
Just the Input Text, what happens behind it, I don't care.

If making a simple "Replace character" (one, has a specific use and in a single window) for a little interpolarity is too complicated:
OK, I'm out.
Enjoy your world as a minority Linuxian.

[Doitsu]

Originally Posted by un_pogaz

Enjoy your world as a minority Linuxian.

This has nothing to do with Linux. If you look at the epub specs, you'll see that users must use URLs for all path references. Therefore, it makes sense to expect users to follow this convention.

[DiapDealer]

Do browsers automatically fix urls for Windows users who use backslashes instead of forward ones? Does Sigil fix any other hrefs where a user mistakenly uses back slashes? The paths to files in epubs are hrefs, not os-specific paths.

If making a simple "Replace character" (one, has a specific use and in a single window) for a little interpolarity is too complicated:
OK, I'm out.
Enjoy your world as a minority Linuxian.

Bye.

As to your ridiculous insinuation that I would ever limit myself to a single operating system: enjoy your naivete.

[jmurphy]

Originally Posted by DiapDealer

Do browsers automatically fix urls for Windows users who use backslashes instead of forward ones?

Nitpick: On Windows at least, both Chrome and (Chromium) Edge do exactly that.

[DiapDealer]

Well would you look at that?

I'm still not really in favor of Sigil doing it. But if someone were to submit a pull request that doesn't break anything else, I'm sure Kevin and I would at least consider incorporating it. I'm just not going to take time to code it up.

[BetterRed]

I often type "http:\\whatever/comes/next.com", current browsers (including firefox) etc don't seem to mind, but it does bother people if I type them like that in a message, email etc .

It makes me wonder if there was a time when URIs did use '\\' after the protocol name.

Why is the '//' there anyway, is the ':' not enough of a delimiter?

BR

[davidfor]

I'm pretty sure that back-slashes where never valid in URI's. But, the URI sort of looks like a file path and that's what Windows uses for the separator, so...

And apparently, the "//" indicates the start of the "authority component". Or at least it does according to the Wikipedia article: https://en.wikipedia.org/wiki/Unifor...rce_Identifier