Don't create Del.Del.Del......sync.ffs_lock files

[NoeNie]

Hi,

I'm trying to use FreeFileSync on a virtual drive created by Cryptomator, which uses https://github.com/dokan-dev/dokany. For some reason, FreeFileSync starts creating files named:

Del.sync.ffs_lock
Del.Del.sync.ffs_lock
Del.Del.Del.sync.ffs_lock
...


It creates about one file every second. This is a problem for most file systems, as the file names soon hit the file name length limit. For Dokany, there seems to be an additional bug (which I will report there), as it allows files with names >256 characters to be created and viewed, but not to be deleted.

On the FreeFileSync side, it would be nice if this chain of files could be recognized and stopped. Either just don't create more files (I suppose they're "created" by "moving" an existing file, but that somehow fails on this filesystem? In that case don't move, but immediately delete if it's already a "Del.*" file), or adopt a different naming scheme, e.g.

Del.sync.ffs_lock
Del.1.sync.ffs_lock
Del.2.sync.ffs_lock
Del.3.sync.ffs_lock


I'd prefer the former solution, as even with short file names, having thousands of new files instead of a completed sync is annoying.

Thanks!

[Zenju]

This looks more like bugs in docany. There should almost never be a reason to create a file named "Del.Del.sync.ffs_lock", except under extremely rare conditions.

Issues like these can be analyzed with: https://freefilesync.org/faq.php#trace

[NoeNie]

Upon closer investigation of the behavior, it seems that FFS fails to delete the ffs_lock file. "Compare"-ing the directory will create a lock file (which isn't deleted anymore). "Synchronize"-ing does the same. Clicking either of these two buttons when a previous lock file hasn't been erased yet results in this chain reaction. My guess: A file system that does not honor deletes will lead to this problem.

I'm looking at the FFS source in Source/base/dir_lock.cpp. So are you saying that abandonedLockDeletionName() would only be executed in extremely rare circumstances? You may be right. 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.

Call stack:
DirLock::ctor()
LockAdmin::retrieve()
SharedDirLock::ctor() // calls in a while loop:
waitOnDirLock() // This is called with increasingly long names, which I can observe through the notifyStatus.
abandonedLockDeletionName() // Augments the filename that was passed in, and calls:
DirLock::ctor()

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).

[Duck_Tape]

Hi to all
I also have the same issue Cryptomator drive for a MS one drive cloud storage
I now have a huge amount of .Del files that I can not delete
any clue to get rid of them

Thanks

[NoeNie]

(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. In my case, that's Dropbox Free, which doesn't support bulk resets, so I would have to manually look at the history online and reset/delete all affected files individually.)

I tried many things unsuccessfully to remove these files: Windows Explorer and `del` on the command line, while Cryptomator mounts the vault with Dokany (this just does nothing when I tell it to delete a file with a long name) or with WebDAV (this does not even show the long file names); Mountain Duck to mount directly (runs terribly slowly, and also cannot delete long file names), or their CLI tool "duck" (claims that those files do not exist, and is too slow to list a directory); and finally the Cryptomator Android app, which is indeed able to delete those files, but they have to be deleted one by one, so if you already have hundreds of them, this would take hours.

Eventually I managed to delete them all at once by using Ubuntu (I already had a VirtualBox machine for that), installing Dropbox+Cryptomator there and mounting the vault, then just using Nautilus to delete or the command line (rm Del.*).

[Duck_Tape]

Thanks for the info NoeNie
For my troubles as its a Microsoft one drive, I can't do quite the same thing as you did, as LInux has no direct support for one drive. I know there are third-party tools to get around that limitation, but for a one-off fix it's to much work. In the end, as its the copy side of the data that has all the .del files I just deleted the whole folder from the one drive which worked fine and am in the process of recreating it. I am not using FFS to do this just windows explorer.

[gauvinalexandre]

Hi,
I also have the same symptom on my system. I'm also using Cryptomator to backup some file between a local disk and an external drive, which contains the encrypted file system. I discovered that after a scan or synchronization of my files, the sync.ffs_lock remains at the root of the encrypted folder. To prevent the generation of the "Del.Del...ffs_lock" files, I have to delete it manually. Cryptomator uses Dokany. Is there a reason why this file would not be deleted after a sync or scan? Also, why are these "Del.Del...ffs_lock" files generated? What's there purpose?
Thanks!

[JacChot]

Hi, same issue here with Cryptomator on Dropbox. More than 400 "Del.Del. ..." files created and now FFS crashes !
Back to Cryptomator v1.4.11 allow to run FFS correctly again.
Please, how delete these files ? Thanks

[bhommi]

Same here. Cryptomator Version 1.4.15. Local drive. What can I do?

[NoeNie]

To prevent this from happening, you need to either update the Dokany version, or remove Dokany in the Windows control panel and reinstall Cryptomator (so that the newest Dokany version gets installed).

To clean up the mess once it happened, see the posts above. In particular, you can use a VM with Ubuntu to delete the files, or you can just create a fresh vault (with the same password) and copy over all files except the Del.* files and then remove the old vault.

[TheGunR]

I suffer from the same problem on Cryptomator 1.4.15 and Windows 10 1903. Couldn't get rid of these files even though I had enabled long pathnamesupport, so I had to boot into Ubuntu as suggested above.

Which version of Dokany fixes the bug described here? (latest is 1.3.0.100). Do I need to downgrade?

[bhommi]

Ok here is another solution for the problem:
- Deinstall the dokan-version 1.2.0 and reboot.
- After that install the dokan-version 1.3.0.100.
After that FreeFileSnyc and cryptomator works again perfect ;-)

Thx for your helps!

[Zenju]

Ok here is another solution for the problem:
- Deinstall the dokan-version 1.2.0 and reboot.
- After that install the dokan-version 1.3.0.100.
After that FreeFileSnyc and cryptomator works again perfect ;-)

Thx for your helps!

Thanks for posting the solution! In any case, the above issues are another reason for FreeFileSync to make "LockDirectoriesDuringSync" a property of a sync job, rather than a global setting, in order to have a workaround at hand to deal with file system bugs like "silent failure to delete files".

[r.gayler]

FWIW I am getting the same issue trying to sync from a Synology NAS using freefilesync 10.13. As far as I know I don't have cyryptomator/dokany on either the source or target system. Interestingly, the problem only occurs for one of the NAS shares I am syncing from.

I can confirm that after upgrading to freefilesync 10.16 the issue has gone away for me. I get a warning message about being unable to set directory locks due to endless recursion. There are 11 FFS lock files left in the source directory after FFS has executed (which while not actually a problem is a bit messy, because I would expect FFS to leave the source directory as it found it).

Screenshot from 2019-10-17 20-50-07.png (59.8 KiB) Viewed 3623 times

[r.gayler]

I have just noticed a weird behaviour which *might* be related to this thread, so I'll post it here rather than start a new thread.

I was using FFS 10.13 to mirror from a source (Synology NAS) to a target (USB external HDD connected to a linux desktop). FFS was executed on the linux desktop.

After mirroring from source to target, I found that all the files on the target drive had a modification date 30 seconds before the modification date of the corresponding files on the source. To be clear, the modification dates of the files spanned many years, but for each pair of corresponding files the modification date on the target was 30 seconds earlier than the source. I confirmed this from the OS, so it's not FFS somehow wrongly reading the modification dates. The files on the target were created by FFS, so FFS has somehow written the wrong modification date to the target files.

Because the source dates are 30 seconds after the target dates, if I run FFS again straight away it says that *all* the target files are out of date and need to be updated.

This happened with FFS 10.13, which gave me the "cannot create lock files" error when I ran it. The amount of time it took FFS to generate that error message and for me to click "ignore" was about 30 seconds - so I wonder if FFS did part of the modified date calculation before the error message and another part after I clicked "ignore", so that the 30 seconds taken to dismiss the error gets used as a 30 second offset in the modification date calculations applied to the target files?

This issue has gone away for me in FFS 10.16, so I don't really care any more. However I am posting this in case someone else runs into something similar, and because it's possible that the root cause hasn't been fixed in FFS 10.16 in which case the issue might re-appear in some other context.