![]() ![]() ![]() But I digress, the main point is that the sync.ffs_lock file wasn't deleted in the first place. This arguably isn't the smartest behavior of FFS, but it only fails badly because of two combined Cryptomator bugs (deletion fails from FFS, and even manual deletion fails for long file names). Soon the file names become long enough to make deletion fail (another Cryptomator/Dokany bug), so you'll never get rid of those files again. After a minute, you'll already have 60 files lying around. But removing that isn't possible either, so it creates _lock and so on. After a timeout of about a second, it realizes that the original isn't going to be deleted, so it attempts to remove _lock with a recursive call to the same function. So FFS will lock on a different file ( _lock) to atomatically delete the original lock file. But it appears to be locked still (the lock file still exists from the comparing). ![]() If you now click "Synchronize" (I suggest you don't and instead skip step 4 here), then FFS will attempt to lock the directory again. There is also no error message, perhaps because FreeFileSync just ignores this error. FFS attempts to remove the lock file, but this does not happen. FFS reads in all the files and displays them on the UI.ģ.3.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |