(REGRESSION) Endeless loop uploading/donwloading in Megasync 5.8.0

[julenuri]

Mega version: MegaSync 5.8.0 client
OS: Windows 10 x64.

Description: Megasync is not correctly checking if the local hosted version is an old version, and tries always to upload the local version to the cloud, and starts a loop of download and upload that get exhausted the bandwidth.

Sometimes, it lead into the GUI crash.

Not sure how to solve that situation. Workaround for me has to be to donwgrade to the 5.6.0 version.

In a second computer that I have with Windows 11 and 5.8.0, I haven't detected the bug.

[rautamiekka]

Sounds somewhat like a FAT32 problem, since FAT32 has a low time resolution (I think it was 1 second ?), but that's the best I have right now.

[julenuri]

Sounds somewhat like a FAT32 problem, since FAT32 has a low time resolution (I think it was 1 second ?), but that's the best I have right now.

Impossible, my device (Windows 10) is obviously NTFS. So... Impossible. There is a failure in the software, and it's recent.

[vtmateos]

Hi @julenuri ,
We would need log files to debug the issue and sharing logs through GitHub is not the best approach.
Please contact our support team at https://mega.io/contact to provide all the necessary information for debugging your issue. You can paste the ticket ID here so we can track your case.
Regards.

[dasebasto]

Same issue here with MegaSync client 5.8.0 on Windows 11 x64, it's driving me crazy. I'm using NTFS exclusively.
Many files end up in upload/download loops and exhaust the bandwidth quota.

I just reported this issue from within the client (2025-03-05 09:37 CET), but did not get a ticket ID.

edit: my 2nd computer runs Windows 10 x64, and it's possible that it might be what causes the bug (I think the Windows 11 PC started going crazy after the Windows 10 PC was turned on and started to sync).

[julenuri]

I will check if I have the logs, but first to take in account... https://www.reddit.com/r/MEGA/comments/1iztw21/comment/mfw5n41/

[vtmateos]

Hi @julenuri ,
Thanks for the feedback, 5.9.0 will be released along next week.

[vageliskatsiotis]

Hi there. Yes, this started to happen to my systems the other day. Issue only occurs while trying to sync folders between Windows and Linux. Arch in my case. Between Windows OSes sync is ok. I don't know if it contributes to something but in my case the MEGA folder is in a different hdd than the OS in all the situations. Haven't had an issue until recently and cannot pinpoint what changed exactly in the directory. Specific 106 specific files keeps rolling over, not the whole folder. I take it that it maybe has something to do with the Linux version of the app, as Windows app seems to sync ok. Hope that helps.

[Tillwoofie]

Hopefully this helps, I started getting this issue a couple days ago when my main Desktop (Windows) updated to version 5.8.0 of MegaSync. I also have it synced to a Linux machine (runs 24/7), and a windows laptop (only on sometimes); both of which were running 5.6.x of MegaSync.

First thing I noticed was the disk on my desktop filled up with local sync rubbish (several hundred GB worth). After clearing that out it looked fine and I didn't notice the background transfers that kept happening, until today when it fully ran me out of transfer limit (1TB).

I had updated the clients on all 3 machines up to 5.8.0 thinking it was just some incompatibility, and started a full resync to the cloud (deleted all files in the affected share in the cloud, restarted sync). With only a single client (the Windows Desktop); it seems to be fine and not try to start looping. After a minute or two of having either of the other clients syncing, it starts trying to loop uploading/downloading files. If I enable "Advanced issue resolution" instead of "smart" it will detect hundreds of files where the dates don't line up, even though they are the same size. Because these are mostly 3D files (blender) and image textures, this rapidly gets out of hand (it ate my 1TB bandwidth in about 5 days).

I just wanted to add this in here with the hopes that it will aid in any troubleshooting if the issue is still being figured out. I will update to the new 5.9.0 as soon as it's available, but for right now it seems to be ok, as long as only 1 client is syncing at all.

[vageliskatsiotis]

Tried today again with latest version but issue still there. Tried Rescan but with no success. Is there a file that the changes are stored/cached and needs to be deleted before? One of the files trying to sync shows as below on the arch linux megasync log:

03/14-19:04:40.551562 134842645739200 DTL Both sides unsynced: Cloud -> mtime: 1587139440, size: 36893384. Local -> mtime: 1587139440, size: 36893384.

03/14-19:12:47.428802 129879240586944 DTL Stall detected! stalled local path (LocalAndRemotePreviouslyUnsyncedDiffer): /path_to_Mega_folder/2018 HR-V Owners Manual.pdf [backupId = 16621602547857389678] [sync.cpp:13527]

[doomdogus]

I can confirm 5.9.0 doesn't fix it. Identical files (checksum validated), with identical dates, on NTFS, are uploaded/downloaded multiple times, going to Rubbish, deleting themselves from the cloud etc.
Something is really wrong with the system, after 11 years (for me) without a single issue...
Please fix it.

[vageliskatsiotis]

I have opened a case with Mega Support for this. It will be fixed in 5.11.0

[julenuri]

Have we located the point of regression? I can't compile Megasync by myself right now... But surely between releases, we can check them.