Restore a read-only file

Bug
#1

Please describe what you are doing to trigger the bug:

Restoring a backup stops upon encountering a read-only file
Please describe what you expect to happen (but doesn’t):

Read-only file should be restored and made read-only once again

Please describe what actually happens (the wrong behaviour):
Restoring stops and I can’t get the file.

I’ve come across the same bug from 2018 but can’t find it again. Glenchen mentioned that some users might be appalled by writing a read-only file, but not having the file is even worse.

I’m using the the [duplicacy_web_installer_win64_1.5.0.exe] version.

#2

I think in most cases you set a file to be read-only because you don’t want it to be accidentally overwritten. If you want to restore to a previous stored in the backup, you should manually remove the read-only attribute before the restore.

1 Like
#3

Thanks for the answer. How can I modify the attribute to rwx while it’s in a chunk?

#4

It’s an attribute of a target file, that may already exist in the filesystem.

#5

Just checked, the file does not exist on the filesystem. As a test I was successfully restoring the backup to the Unraid machine the original data (ext4) resides. So it may have to do something with Windows (ntfs). This is the log of the recent restore attempt:

2021-03-09 19:23:46.862 INFO REPOSITORY_SET Repository set to XXX

2021-03-09 19:23:46.862 INFO STORAGE_SET Storage set to odb://XX

2021-03-09 19:23:48.653 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)

2021-03-09 19:23:49.590 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path

2021-03-09 19:23:51.000 INFO SNAPSHOT_FILTER Parsing filter file \?\C:\Users\XX.duplicacy-web\repositories\localhost\restore.duplicacy\filters

2021-03-09 19:23:51.000 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)

2021-03-09 19:23:51.587 INFO RESTORE_START Restoring D:/XXX to revision 1

2021-03-09 19:23:51.843 ERROR DOWNLOAD_CREATE Failed to create the file \?\D:\XX\fahrgastrechteformular XX -> XX 22.06.20.pdf for in-place writing

Options used are: -stats -threads 4 -ignore-owner -persist

#6

I just noticed that the file to be restored had an Umlaut in it. However, the filename was changed from Zöffenhausen to Zöffenhausen. Maybe that has something to do with the error on Windows?