I've prepared a shared folder that demonstrates the issue in 4.8.1, to clarify this case and hopefully justify this change and set your mind and others at ease. It's just starting a folder download to a non-empty target and has to figure it out as it goes based on what it can see in the cloud and local folders. However, although you know you haven't changed the files there, on your second download MEGAsync hasn't recorded that or any info about what changed locally or remotely. Hi, thanks for the demo folder, and I see what you're saying. MEGAsync 4.9.3 doesn't check for the files and downloads all of them again. MEGAsync 4.8.5 checks for the files you already downloaded and skips those unless they were updated in the shared folder. The use case is downloading a shared folder that gets updated every couple days or weeks. It's about MEGAsync dowloading files again that were already downloaded.

This issue isn't about resuming downloads. Or if there is something more complicated and unusual about your case then please let us know what that is so we can reproduce the issue. But if it was a 4.9.3 download, 4.9.3 can resume it.

So if your 4.9.3 was resuming a download from a prior version, that may be why you saw a case that didn't work. The fix did require adding one more field to the transfer database record, if that is not present then it can't resume. I've just double checked in 4.9.3, exiting the app in the middle of a 1gb download, and it resumed fine. Hi, that bug was fixed, and the fix is present in 4.9.3. This is especially problematic with single files that are larger than the free transfer limit, since if you need to close the mega app before that 8 hour timeout (or however long it is) expires you will never download the complete file. If you attempt to download a file and it gets interrupted for any reason, like your computer restarts or megasync restarts or your internet connection changes, megasync will NOT recognize the previously in-progress download the next time it launches, it will attempt to restart downloading that file from 0. The problem is that resuming interrupted downloads from a hidden temporary file (.) simply does not work. Hi, could you please explain your use case, why are you downloading the same file to the same location again? And, is it enough that there is already a file present with the right name or would you want to ensure that the file at that location really is identical to the one in the cloud, or perhaps overwrite it to be sure? thanks

MEGAsync 4.9.6 free instals