Here is a scenario that I have not currently tested, but I can see it being plausible: I make backups on my Linux PC. Obviously the filesystem allows for pretty much all characters as file/directory names. On my Linux PC, I may have directories such as “Foo: Bar”, which is perfectly fine. However, this is not a valid directory name for Windows. What would happen if I tried to restore the repository on Windows? Will Kopia error out? Or, will it be able to automatically rename files/directories to avoid the issue?
There’s no automatic rename support yet, so it will probably error out. Note you can also “restore” to a zip or tar file, which will both preserve invalid characters.
I’ll be happy to accept/review a PRs that add support for automatic rename on restore.
1 Like
Hello,
I’m in this exact situation.
I backuped on Linux and restored on Windows.
I have directory names with “:” on them.
It does in fact error out.
What can I do right now? Can I rename those folders from kopia in some way?
It is also unclear what restoring file permissions and file ownership would mean in this context.
I had to uncheck that options otherwise the restore would not work.
Install some Linux VM and restore there. Then you can do whatever you like including renaming problematic names before transferring to Windows disk.
I don’t have the time for this.
Moreover my backup is over 400 GB, I would need a 500 GB VM to do that.
Then I would need to restore the backup 2 times (first on the linux vm, and somehow transfer it to the host machine)
I’m restoring the backup one folder at a time.
I’m restoring the urgent things that I need to plan my days and do my work first.
Fortunately the problematic files are on “optional” folders.
We will see when we get there, but I need urgently to restore the backup to work right now.
I really think we should have an automatic rename option and/or the option to rename files in the snapshot.
Thanks for your proposal anyway,
Feel free to submit PR:) or wait until somebody will consider it important enough to do it.
Ah, forgot to say
I mounted the snapshot as a filesystem volume, but it doesn’t allow me to rename the files there, and using robocopy to copy from the volume doesn’t copy the big files over
50MB max on Windows. Some WebDAV limitation.
Instead of full VM you can install WSL and restore problematic data there. Few minutes job.
Will WSL give me a BTRFS/ETX4 partition where I can restore the files with commas and colons in filenames?
It is Linux. So you can do whatever it supports, including ext4/btrfs file systems. If not enough space on your internal disk you can always use some external scrap disk.
https://www.reddit.com/r/wsl2/comments/12chsty/wsl2_mount_ext4_on_windows_10/
I restored to a .tar file hoping I could rename files inside it with 7zip.
In reality Windows decompressed the tar file apparently without problems.
Although 7zip was not able to open one of them, but did open the other
Nope.
7zip is not opening those .tar files created by Kopia, and although Windows Explorer decompresses them, some folders are empty when they shouldn’t.
Also, I discovered that “@” doesn’t seem to be an invalid character for Windows filenames, so it’s not even a problem of invalid characters. THe generated .tar are corrupted.
Also the zip files generated by Kopia are corrupted.
If you run them through “7z t”, it will tell you the headers are corrupted:
"C:\Program Files\7-Zip\7z" t FILE.zip
7-Zip 24.09 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-11-29
Scanning the drive for archives:
1 file, 39970366710 bytes (38 GiB)
Testing archive: FILE.zip
WARNINGS:
Headers Error
--
Path = FILE.zip
Type = zip
WARNINGS:
Headers Error
Physical Size = 39970366710
64-bit = +
Characteristics = Zip64
Everything is Ok
Archives with Warnings: 1
Warnings: 1
Files: 1701
Size: 39969738504
Compressed: 39970366710
but at least they can be decompressed anyway
For the record, in the end I’m restoring a zip file I created before formatting the system and saved in a NTFS partition of a SSD (I have 4 backups: Kopia, restic, the zip file, and online).
The simplest solution proved to be the better one.
This will need some kind of decision about how to represent the output names, since there are a lot of ways to do it, and then you need to figure out if you need to do it in reverse if you ever back up this restore again. For instance, url-encoding means you replace space with %20 and so on, but people have such files in their Download folders already. How to know if kopia was the one making the %xx once before or if it was an artifact of browser downloading a file with spaces in it? In one case you want to transform it back, in the other probably not.
For unix file systems, all byte values are valid for filename, except “/” and NULL (0x00). NTFS actually allows a lot, but the OS and the Explorer shell places additional limits on valid file names that isn’t inherent in NTFS, and some of the names the explorer prevents can be created with a program but not necessarily entered in a gui. So as soon as you start making allowances for transforming the names via some engine or ruleset, you need to make sure that the result is “usable”. Apart from : being a bad choice for looking like devices on Win OS, you have all the PRT/CON/NIL names that have been causing issues for 30+ years.
A summary of things to handle is found here:
It is quite the mess and I do not envy the one that wants to try to code this up in a neat reversible fashion.