SyncBack Pro looping when using compression

Windows 10 pro x64 22H2 with latest updates.
SyncBack Pro v10.2.129 (first noticed on v10.2.68)
Cryptomator v1.9.1 (first noticed on v1.8.0)
Neither SyncBack nor Cryptomator are running elevated as admin.

SyncBack profile source reads from a normal NTFS folder. The destination is a Cryptomator volume configured to use “WinFSP (Local Drive)”, mounted to a directory.

The SyncBack backup profile is configured to use compression (each individual file is compressed and destination file has .zipx added). Originally the problem was experienced using SyncBack’s “Fast Backup” mode, but it happens even in Mirror (and presumably any mode that has need to rescan the destination files on subsequent runs).

The first sync goes ahead without problems. On subsequent runs, if any destination directory contains hundreds of files, then the rescan goes into a loop and execution never gets any further.

Note that SyncBack profiles that do not use compression do not experience the problem.

 

My testing so far here seems to show the problem happens when the destination contains more than 320 files (starts somewhere between 310 and 320), but I guess it could be a buffer problem that is partly dependent on path lengths rather than just the number of files.

I first sent a problem description to 2BrightSparks (makers of SyncBack) and they studied the problem form their side. Their response was:

We observed that when requesting Windows to return the list of files in a directory it enters into an infinite loop without ever completing. Therefore, we suspect that the reading of the compressed file is somehow causing problems with your Cryptomator volume so it keeps resetting back to the beginning of the directory listing. There is no feasible solution within SyncBack to address this problem, SyncBack must open the Zip file in the destination to get the details.

And so here I am. :slight_smile:

It seems as if the particular combination of hundreds of files being scanned, and zip files being read during that scan, is causing problems for Cryptomator or WinFsp.

What next steps to try and solve this?

 

Background: This started as a way of getting encryption and compression for my backup. Cryptomator gives me encryption but not compression, SyncBack gives me compression (and it can do encryption but encrypting file names introduces other issues). Since I’m using compression I also use SyncBack’s “Fast Backup” which means it rarely needs to rescan the destination. And since all this works for most of my sources, it took a while before I hit the problem (reconfigured a profile that included some large directories, which meant it had to rescan the destination), and longer still to get to this point.

Typical folders where I am seeing this problem are generated source documentation (html file from doxygen etc.), and also subversion repositories.

Not sure if it should have been obvious or not, but the problem does not occur if the backup destination is a normal NTFS drive.

The problem also does NOT happen when the destination is a Cryptomator volume using “WebDav (Windows Explorer)”, I didn’t bother to try HTTP. The backup is very slow this way.

BUT the problem DOES happen when the destination is a Cryptomator volume using WinFsp - no big surprise there, it’s looking like WinFsp is the underlying issue here.

It’s a shame dokany was dropped, it might have been interesting to try that.

Should I be trying this out against WinFsp directly, do you think? I see they have a “MemFS” for testing, so maybe I can try and replicate against that.

I have not yet done a direct WinFsp test, but I did find this bug report, fixed in WinFsp 2023: Unable to build .NET projects inside a WinFSP filesystem

As I understand it, (at least part of) that bug boils down to issues when multiple threads access the same directory - in particular, some duplications.

I’m tempted to install WinFsp 2023 and try it out, but also nervous about compatibility with Cryptomator v1.9.1 (actually, I see v1.9.2 is out now, but still on WinFsp 2022.2). The release notes for WinFsp 2023 say “There are no backwards incompatible API changes in this release, but nevertheless enough things change that warrant a version change.” So reassurance and warning in a single sentence. :worried:

I uninstalled WinFsp 2022.2 and installed WinFsp 2023 and now the problem appears to be solved. I tried all my test SyncBack profiles against Cryptomator using “WinFsp (Local Drive)” and just “WinFsp”, and they all went through without any problems.

So that much is good news but leads to the question: How nervous should I be using WinFsp v2 (2023) when current releases of Cryptomator are only being released with v1.12 (2022.2) ??? Has anyone else been using this combination?

Not all. As the developer of WinFSP wrote, there are no API changes, WinFSP is still discovered by Cryptomator and can be used.

With 1.10.0 we actually plan to upgrade WinFSP in a user friendly way: Feature: Update to WinFsp 2.x and uninstall old winfsp in Windows EXE installer by infeo · Pull Request #3026 · cryptomator/cryptomator · GitHub

Thanks for the reassurance. It does indeed seem to be working smoothly for me so far.