windows: normalize backslashes to slashes

[ThomasWaldmann]

with borg's native windows build, users might use backslashes for pathes when invoking borg.

as borg is platform-independent, it should be possible to extract data archived on windows on e.g. linux, so i guess we do not want to have backslashes in archived item metadata, but only forward slashes.

there might be also some code in borg, that only works correctly for slashes, not sure.

so the idea is to normalize to forward slashes:

borg create repo::archive \some\path1 -> borg create repo::archive /some/path

In the archive (borg list), this needs to look like some/path later as borg only stores relative pathes.

Guess this can be done by using a special argparse validator for processing path-like cli arguments that does the transformation.

Guess it is wise to completely ignore the existence of drive letters to limit the scope of the fix to just path separators working as they should. We can just assume that we only archive data from the current drive and a drive letter is not used within cli arguments.

Later, fix drive letters (only) in a separate PR.

[ThomasWaldmann]

This refers to code in #4696 (master branch after that is merged).

[jrast]

I was thinking about this and some questions poped up about the path handling:

• Borg only stores relative paths, is this correct? The path is relative to the PATH given on the command line?
• The idea is to store all path in unix format (forward slashes) even if the backup is run on windows?
• How should exclude (shell-)patterns behave? For example, should we use foo/**/bar or foo\**\bar on windows? Currently borg checks for the platform specific path separator.

[ThomasWaldmann]

• yes. no (just have a look...).
• yes. iirc, slashes also work on windows. and it must be slashes when extracting on linux.
• normalize all to forward slashes / reject all backslashes as early as possible?

[jrast]

Is this correct: If a relative path is given as PATH, then the relative path is stored in the repo. If an absolute path is given, the first / is stripped to make the path look relative? At least thats the behaviour I see in my test.

[jrast]

@ThomasWaldmann can you confirm my observation of the comment above?

Converting backslashes to slashes is possible, however, how should we handle drive letters? One solution would be to convert a path like D:\Folder\MyData to d/Folder/MyData.

However, I think this behaviour would be very unexpected for Windows users. If I create a backup and list the content, I expect to see the paths unaltered.

[ThomasWaldmann]

guess there are 2 easy options:

• not storing a drive letter at all. users can create different archives for different drives.
• as you suggested, using c/windows/... or d/something/...

using a drive letter in an archive would lead to troubles when trying:

• to extract on linux (no drive letters there)
• to extract on windows - as the usual behaviour is NOT to extract to an absolute path, but to one relative to the cwd.

[fantasya-pbem]

* not storing a drive letter at all. users can create different archives for different drives.

If this was implemented, maybe the drive letter could be stored in the archive object metadata? Then the archive could be extracted on Linux too, and all paths would be interpreted as relative.

[jrast]

• to extract on windows - as the usual behaviour is NOT to extract to an absolute path, but to one relative to the cwd.

Ok, you convinced me. I will think again what is better: Forcing the user to create different archives for the different drives or converting the path.

[ThomasWaldmann]

I think it should be "different archives". Users expect to do a useful full-archive extraction.

Assume the user is in c:/extract/ directory and does borg extract repo::win-c-d-drive and we stored pathes like c/windows/..., d/mydata/....

It would then create subdirectories c and d below c:/extract/ with all the stuff.

The c stuff is somehow ok, the user can afterwards efficiently move it to the correct place on the C: filesystem.

But the d stuff can not just be moved, it will need expensive copying to D: filesystem and removing from C: filesystem again.