(Note for others: Depending on the syncing service you use behind Cryptomator, you might be able to leverage that to reset to a certain state.
#MOUNTAIN DUCK DELELET FOLDER NOT WORKING CODE#
Setting aside the annoyingly many files that are being created, I'd say that a potential infinite recursion is a code smell (there's nothing fundamental in the code that prevents infinite recursion and thus a stack overflow). WaitOnDirLock() // This is called with increasingly long names, which I can observe through the notifyStatus.ĪbandonedLockDeletionName() // Augments the filename that was passed in, and calls: SharedDirLock::ctor() // calls in a while loop: The problem is that, if the circumstances happen under which it is called, and those circumstances don't change, then it is called a lot.
So are you saying that abandonedLockDeletionName() would only be executed in extremely rare circumstances? You may be right. I'm looking at the FFS source in Source/base/dir_lock.cpp. My guess: A file system that does not honor deletes will lead to this problem. Clicking either of these two buttons when a previous lock file hasn't been erased yet results in this chain reaction.
"Compare"-ing the directory will create a lock file (which isn't deleted anymore). Upon closer investigation of the behavior, it seems that FFS fails to delete the ffs_lock file.
0 kommentar(er)
