I’ve just migrated a 426GB backup vault from 1.4.15 to 1.5b2. Here is the main stats and feedback of how i tested.
In summary - the migration was fast and successful. Modification times on files were preserved. however many Folders times were changed to the migration time.
Host PC : Linux mint 19.3
Cloud platform : Pcloud (via the official client)
Connection : Residential Fibre 80Mb/s download 20Mb/s - 8 megabyte 2 megabyte.
Backup Synced from local file systems, to cryptomator 1.4 before the migration.
Pre migration stats - 77665 files/dirs in the unlocked vault.
Externally to the file system this shows as D folder 79684 items and M folder 5373 items.
Pcloud local cache synced then cleared before starting the migration.
1.50 migration time - 12 minutes.
(the pcloud fuse client is very efficient in making file listings locally then queuing the change operations to upload at its own pace. Much smoother and more efficient than e.g. webdav. It also preserves modification times)
Post migration stats. D folder : 80947 items (previously 79684 items) M folder : deleted (previously 5373 items)
Data verified/compared local to 1.5.0 vault "rsync -r -t -v
SUCCESS: all files and their modification dates preserved
CHANGES/POTENTIAL ISSUES:Most folders appear to have a modtime set between 18:00 and 18:15 today, which was during the migration. However nested folders deep in the vault appear to have preserved the original folder time. It appears to be if they are more than 3 folders deep. My backup scenario does not care about folder times, only files - so this is not an issue for me.
@SailReal@overheadhunter If you guys need further feedback on the migration, I’ve retained log (24MB!) and can provide more info on my setup if there’s anything specific that helps with the feedback/beta test. Please just let me know .
Thanks for sharing your feedback. I don’t quite understand the date change yet, because directories should not have been touched at all, but I think we will figure it out.
I think the date change is related to folders that have metadata previously in the M folder. When the new folder is created for metadata such as a dir.c9r file , the dates are affected there.
Example
Level 1 - P6/ - Date , 23 oct 2019
Level 2 - P6/P7NXxxxxxxxxxx/ 8 feb 2020
Level 3 - P7/P7NXxxxxxx/UKwKxxxxxx.c9r/ 8 Feb 2020
dir.c9r at level 3 23 June 2018
Ah yes, those “Level 3” directories didn’t previously exist, so they are expected to have been modified lately. The date that is displayed on the cleartext directories should be the one of the dir.c9r file, so you should not see any date changes inside the unlocked vault, or do you?
I do see changes in the Unlocked vault on folder modtimes - is almost the complete opposite!
Level1 DIR- Migration time
Level1/Level2 DIR- Migration time
Level1/Level2 DIR - Original Time
Level1/Level2/Level3 DIR … - Original Time.
FILES within Every Level have perfectly preserved modtimes.
This is really not an issue for me at all, just trying to provide some comprehensive beta feedback…- as an Rsync backup target I only care about File Modtime or CRC inside the vault.
Thoughts/questions.
Are level 1+2 folders in the Unlocked vault handled differently than 3+ internally in cryptomator?
Changes to folders on pcloud, such as renaming folders will change the modtime… Are these changes to times Externally ( eg new metadata folders) getting passed to cryptomator and affecting the unlocked vault?
Pclouds mounted on a fuse filesystem. - If this had been a webdav target, (many not supporting modtime) , would the File modtimes have changed too due to every file being renamed to a .c9r ?
I have to correct my previous statement about the dir.c9r file: The modification time of cleartext directories (regardless of their level) is always read from the ciphertext directory at the second level below the d dir (e.g. your aforementioned P6/P7NXxxxxxxxxxx ).
However, those directories have not been renamed during migration. Unless changing its contents (like adding a subdirectory) is considered a change for pcloud.
This would mean that the updated modification time does not depend on the level per se but rather on the fact whether a directory contains a subdirectory. Do you find any evidence supporting this hypothesis?
This might be easier to follow / explain.
I created a test vault in 1.4.15 No folders or nested files were created after 10.28AM Migration was at 10:30am exactly. Wherever you see a 10:30 on a folder its caused by the migration.
Again it is only 2 levels deep, doesnt affect level 3 (foldera3) . Also folders with no “nesting” preserve time (folderc)
here is LS output inside the Unlocked migrated vault.
Can you edit your above comments and replace the ls -l outputs by a tree -D? I think this might be easier to read.
After some reading I think it is considered normal that a folder’s modification time changes when adding/removing or renaming child nodes. I’m not sure if we should restore the original modification date or if this would interfere with cloud sync software. @tobihagemann any opinion on this?
