![]() ![]() And yet rm or unlink executed under MinGW cannot reproduce the problem, and also del from the Windows command line or Windows Explorer succeed in deleting files if their names are reasonably short.FreeFileSync is a free/open source folder and file synchronization program that features a beautiful, two pane user interface and a host of powerful options. Besides the widespread error swallowing, this looks like quite a normal way to delete a file. Note in particular the file FreeFileSync/Source/base/dir_lock.cpp and zen/file_access.cpp where the removeFilePlain() helper calls through to unlink() (not sure from which header). Additional InformationįreeFileSync is open source, you can grab the code here. No matter if Dropbox is running or not, no matter the FreeFileSync version, on both my laptop and my desktop machine. The files are deleted just like they were with Cryptomator 1.4.11. In conclusion: Whatever kinds of files FFS tries to delete (regular user files, the magic lock file or the magic database file), the deletion just silently fails on Cryptomator 1.4.15 with Dokany. This time, you will additionally see it fail to move the temp database file to main database file because it failed to delete the latter previously. Optional: For another iteration, delete lock file again, compare again, delete lock file again, sync again.When the sync is done, FFS will neither have deleted its lock file (like above) nor the file you created in step (1.).It will warn you that the recycling bin isn't available in the vault, which is expected. After doing that, you can safely hit "Synchronize". For a further test, tell FFS to sync the file you created in step (1.) from right to left, i.e. If you want to continue using FFS "normally", you need to help it by deleting the lock file manually.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. Point FreeFileSync (FFS) to that vault on the left side, and an entirely empty directory (outside any vaults) on the right side.ģ.1.FreeFileSync 10.15 (it reproduces equally with 10.11, so the presence of the bug is solely determined by the Cryptomator version that I'm using, see above).Dropbox `79.4.143´ (though the problem reproduces even with Dropbox turned off).Cryptomator version: 1.4.15 can reproduce the problem, 1.4.11 works fine.Operating system and version: Windows 10 Pro with all updates installed.For the magic files, this results in deadlocks that can be difficult to clean up. ![]() For regular user files, this just results in an incorrect syncing outcome. And yet the problem started appearing with a new Cryptomator version. FreeFileSync can't delete files, but it works from Explorer/CLI. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |