I set up to transfer a 1.3Tb file, it said 600GB was transferred, then everything stopped. On the server it says that the information is up to date, on the client the synchronization hangs endlessly. At the same time inside the file, the size of 1.3Tb is just zeros… The file system is NTFS, all this time the data was flowing, but why the file has just zeros?
Is there some kind of limit on the file size?
I don’t think so, but if it was interrupted/restarted it will need to hash the 1.3 TB temp file to figure out which blocks still need to be transferred, which can take a while. Places were blocks are not written yet will be zeroes.
For that size of files, I would probably look into some other more specialised tool, perhaps one that does in-place updates. Syncthing doesn’t which is going to suck if this file is updated with any frequency.
My goal is just to transfer occasional files of 1TB or more. A file was transferred to 600GB, for some reason the transfer stopped, I looked in the file and it is completely made up of zeros. It’s as if those 600GB were never written to disk at all. Then it does nothing, there is no access to the program disk neither on the client nor on the server.
I read that there are no restrictions on folders, but there are? I repeated this situation twice, and twice with the same result, only the second time I saw that the file was empty. 
Could you provide more details on what you mean by “program disk”?
What type of files are you transferring and are they in use by another program while transferring?
How much unused space is on the destination drive?
What I mean is that neither the client program nor the server program accesses the file in order to compare its contents and continue downloading it. This is not such a big problem though, because 600GB just disappeared and was not written to disk for some reason.
No other applications use these files, also this folder is excluded from antivirus scans.
The *tibx file is an Acronis Image File.
There is 4TB free on the client machine.
Check out Synthing’s log file, plus optionally enable some of the debugging facilities. There’s currently not enough info to diagnose this (there are quite a few possible causes, not necessarily related to Syncthing).
So no need to account for sparse files.
When Syncthing is updating an existing file, it requires enough storage space to temporarily hold both the old and new versions.
On a related note…
Based on your earlier description, a combination of OpenSSH + Rclone would be a better fit than Syncthing.
Each sync would take a lot less time and system resources. And because Acronis backups are split across multiple files, you can trigger a sync after a backup is complete versus Syncthing starting a sync shortly after a piece of a backup is written to disk.
If you’re running Windows 10/11, a OpenSSH package is available from Microsoft. Enable the sshd service, then configure Rclone to sync files via SFTP (see https://rclone.org/commands/rclone_sync/).
Using the `–inplace`` option while updating existing files reduces the storage space requirements.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.