I'm experiencing this since a few weeks now and finally had some time to look into it in more depth. I was able to reproduce the issue now.
My scenario
When I select the option to compress data using 7z format and create compressed packages (many files per archive), the job fails as soon as the last file has been added to the archive. I experience this only with larger source directories - in my test I used 2000 files with 10 MB each (20GB). This only occurs when I select the 7z format and the job is executed by scheduler or manually in background. However, it won't fail, if I run the job in attended mode with preview. I can run the same job in background successfully when switching to ZIP instead of 7z format.
My real world use case is that I'd like to store photo galleries and other data on a cloud storage. To protect my data, I use encryption (ZIP 265 AES) and also prefer to hide filenames. Using ZIP option, I can only create a protected archive, but cannot hide file names. With 7z format also the file names are protected within the archives. I especially want to go for the compressed packages option and do not want to compress and encrypt each file individually.
Some more details
Version: 10.3.2 (64-bit)
OS: Windows Server 2022 21H2
Job is configured to use Standard copying from left to right (local directories), under Compress/Encrypt format 7z and option "use compressed packages" is selected. Thats all.
Job configuration:
https://i.imgur.com/htGcTje.png
https://i.imgur.com/YQ0nm9z.png
Error message:
Job starts either manually in background or by scheduler, it enumerates all files in the given left folder path and creates 7z file in the "temporary file directory". Once it reaches the last file, the job fails with the error message below.
INCOMPLETE: Error creating compressed package(s). Operation may be incomplete!
Forced closing Job Mutex due to inactivity
Job Mutex freed for profile TEST 7zip compressed package, thread no longer exists
Code: Select all
Main Copying Phase Started At 2/12/2023 5:55:01 PM
Copy L->R G:\TestSyncovery\left\00000000.dat (10.0MB)
Copy L->R G:\TestSyncovery\left\00000001.dat (10.0MB)
[...]
Copy L->R G:\TestSyncovery\left\00002000.dat (10.0MB)
Deleting archive G:\App_SyncoveryTemp\Top Level-2023-02-12 17.55.01.7z after exception The operation was canceled by the user
Error zipping: Operation Canceled
For testing I used some generic data, which I've generated with the PowerShell code below. Syncovery behaves with this data similar to the original data I want to copy.
Code: Select all
$Path = 'G:\SyncoveryTest\left'
New-Item -ItemType Directory -Path $Path
(0..2000) | % {
$f = New-Object System.IO.FileStream "$($Path)\$('{0:d8}' -f $_).dat", Create, ReadWrite
$f.SetLength(10MB)
$f.Close()
}
EDIT - what I've tried so far
* run manually (Attended mode) - works
* use ZIP instead of 7z format - works
* Windows Defender folder exception + disable real-time protection - does not work
* Enable option "compress directly to destination" - works and also fixes issue as long as source data remains the same