Catalina, Duplicati version 2.0.5.1_beta_2020-01-18, Mono version 6.10.0.104
I am testing to backup my files with Duplicati. When I tested the Restoring of files I ran into a serious problem:
Pages, Numbers, Keynote files in package format cannot be restored!
In older versions of iWorks the documents were stored as default as a package. In newer version the default is ZIP, but still can be stored as package.
So if I restore such a file in ZIP format (single file) there is no problem. Bu if the file is in package format, the folder for restoring is destroyed by changing it itself to a package!
Is there a workaround?
Welcome to the forum @Guntherw
It would be best if a macOS expert helped. I don’t use macOS. Meanwhile, here are some tests to try.
How to show or hide file extensions in Mac OS X is a way to view full folder name to investigate issue.
iWork packages, like any package format that Finder knows, seem to be known by folder extensions.
Document packages should always have an extension to identify them—even though that extension may be hidden by the user. The extension allows the Finder to identify your document directory and treat it as a package.
I think you can right click on a package to run “Show Package Contents” if you want to look inside, and maybe there you will find the original “folder for restoring” file content that Finder was hiding from you.
Because package format is a Finder feature, I would expect Duplicati to show raw folder and content.
What do you see in the Restore tree view, and what exactly do you check to restore? Package folder? Some folder above the package folder? Manual checkmarking of files seen below the package folder?
Are you doing Restore to original location or a new folder path? The latter will by default skip creating a deeper upper folder structure than needed. dont-compress-restore-paths option can be set if you wish.
Thank you for your answer.
Finder knows three programs which can save in Package format with the file extensions „numbers“, „pages“ and „key“.
All have the same folders inside (Data, Metadata) and files (Index.zip and three jpg-files ).
I did the following testing:
- Backup of a folder with a bunch of files w package + w/o package
- No warning, no errors
- In the backup the files with Package are shown as folders. I could restore part of the package if I wanted
- Restoring of a file w package out of that folder into a different folder on the same harddisk called „test“ (overwriting)
- Successful, no error, no warning
- Result: The folder has disappeared. Instead there is now a file symbol with the name „test“ in Package format.
- If I open the package of the new file „test“, it has the same content as the original file in the backup.
- It can’t be opened with Pages any more
- Same backup but restoring the whole folder with mixed files
- No problem
- Same backup but restoring one file w package and one file w/o package
- No problem
- Same backup but restoring two files w package
- No problem
Conclusion:
The problem seems only to happen if a single file w package is restored
If Finder allows it (and I think I linked to directions), could this be rewritten without reference to package?
Also, please refer to folder and file precisely, otherwise things like “single file w package” make no sense.
Doesn’t Finder let you see what is truly there, e.g. by using a different symbol? This line is confusing too:
We both have linked to or given the special folder extension that causes a folder to be treated as package.
What do you actually have there, if full name is truly the four characters test, without package extension?
And how can it be package format if it’s a file? Neither Duplicati nor I are expert in how Finder behaves…
Sorry if I confuse you.
Of course I could change the package format of all iWorks files into zip format: the problem would be over. But I have many older files hidden in many folders …
I backed up „dream.pages“. It was saved in package format, meaning you can open the package like a folder with subfolders and files in it.
When I tried to restore „dream.pages“ to a folder called „test“ on the same harddisk, there was after the restore process no „dream.pages“ to be seen.
Instead the folder „test“ was not a normal folder any more. That means I could not open it any more with a double click.
The name „test“ stayed without an extension. And it was in package format, meaning you could open it the same way as „dream.pages“ and it had the same content.
When I now added the extension „.pages“ to „test“ it became „test.pages“. It behaved like a normal Pages file and I was able to open it with the program Pages. It was now identical with „dream.pages“ except the name.
I hope I was able to explain it better.
That’s because the files within the folder share a common upper folder structure (path prefix) that was removed because dont-compress-restore-paths was not set. So after that, only the files below remain.
I would have expected it to not be openable as a package, but Internet suggests it should open as folder.
If you made a folder called test, and put some random file into it by hand, will it open? What if you move index.zip and jpg files in it, such as the ones from original package? That’s all that Duplicati’s going to do. Duplicati has no special knowledge of things that might be required to put things together in Finder way.
That’s as expected. Duplicati thinks it’s a folder. It’s not going to know that it should rename it for Finder.
“way” is apparently not a double click, because of earlier “could not open it any more with a double click.”
What’s not said is if “way” is Finder or Pages, however later rename of folder to test.pages got all OK.
If this means a single folder with package extension, that’s explained above, and if you do two folders with package extensions at the same level, the different folder names force Duplicati to keep the folder names.
So basically the behavior of path prefix removal gets in the way of single package restores, but this can be avoided (I think – you have to test) by either creating the restore folder with a package-type folder name, or restoring several packages to force package folder name restore, or setting dont-compress-restore-paths then descending the folder tree to get to the package you want (to move it where you want), or to restore to original location, where a prefix-path removal may help you by simply restoring the files inside to the folder.