-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restoring paths which are not valid on windows #1205
Comments
Thanks for reporting @andrey-infinity.
So, either the path was not created by the first command, or the second command fails even so the parent path exists..?!? This is all standard Rust functionality, don't know why this shouldn't work... Can you please check if that dir was correctly created? |
I might be wrong but I think that the issue is with trailing space after
Windows most likely saves it without the space: and it breaks rustic logic in some way. Windows is disaster here as its filesystem allows it but user space tools not. So with a little bit trickery it is possible to create file or directory no standard Windows tool can delete... and other similar nonsense situations unheard in normal OS:) |
@kapitainsky, this does sound like it, since I remember some other files failed to restore using Would that be in project guideline, after making a backup to output a report with found incompatibilities. I would be happy to get report such as: "Found 10 files that will have problems restoring on windows" Having said that, when the problem is explained, it doesn't block me. |
Good if this is the case as at least we know what is causing it. And for sure this is a bug that In general it is something to pay attention too - how illegal characters are handled. For example |
@kapitainsky Thanks for your answer! I also suspected that this is something like this. I just wonder what is the best way to handle this. Leading/trailing whitespaces are allowed on *nix and are of course supported by the repository format. So yet, most likely the best way to handle this is to display an error and proceed - and ideally show at the end "x error occured during restore" with an non-zero exit code. This kind of error handling is anyway open. Another possibility would be to add an (windows-only?) option like |
I would be strongly against it... as it opens can of worms with all exceptions and edge cases. I think logic should be clean - something is supported then it is restores. If not then error is produced and restoration job continues. It is user responsibility to ensure cross platform compatibility - path lengths, characters used etc. The key is error handling and logging. In this particular case I can imagine that dir without trailing space is created but error is logged that restoration of it had problem maybe with a hint to check cross platform compatibility (length, characters used). |
Actually there is the possibility to always restore to individual paths/names: In this case something like
(note the trailing space is included in the snapshot path and excluded in the target, might however need some escaping depending on the shell you are calling this) should actually work . |
One more thought. This is absolutely not Windows specific problem as suggested wrongly in the title now . The real issue here is that I can be on Linux restoring locally created backup but my destination can be different filesystem (NFS/SMB/FUSE mounted for example) with very different restrictions. Two things can happen in general I think:
There should be flag to stop on error if user wishes but by default IMO all process should continue regardless of errors. Good example is lack of space error - It can be just one item too big to fit into remaining space but actually all other items can be restored. Above outlined behaviour should always work regardless of given situation restrictions. I would be totally against trying to handle specific cases like e.g. trailing spaces in Windows. It would be never ending quest to get it right. In ideal world |
I agree with the (soft) error handling debate and think this should be handled gracefully and restoring should be continuing, and an error being logged. I do think, that changing the filename could lead to problems down the line - so I agree we shouldn't go down this rabbit hole. IMHO we should make it easy to see and understand what is the error and then even give some advice how to restore that file, e.g. give a composited command to copy and paste from/to terminal to restore this file. This would make it easy for the user to handle this error, as they could just use the printed command and copy them to their terminal. |
Made a backup on MacOs M2 with following command
rustic -r mac-data backup /Volumes/Data
using rustic v0.7.0Later tried to restore it with rustic v0.8.0 using command:
Restore: PS R:\> .\rustic.exe -r mac-data restore latest R:\
Got a following crash report.
Also tried to restore it with
restic
- also got bunch of errors that some files cannot be read. Total size is 100k files and 309GB.report-b21314ad-079a-403c-a7c7-f72247063914.txt
The text was updated successfully, but these errors were encountered: