![]() My logical instinct says that there is something wrong with the way MegaSync handles filechanges. What happens for me very often is that when other Computers with the sync setup have been offline for a day or two, I changed file location, names or deleted some, and they don't receive the new state of these files. Note that having the share set to read-only, also means that it could very well be that Computer X is offline. Witness files being downloaded that you renamed or moved earlier.Let the other contact set up the (shared) folder sync in the settings/SYNCS tab on his computer.Set the share to 'full access' with the other contact (computer X).Change the filename and location of a number of files (in windows explorer).Make the share with the other contact, set it to read-only (he downloads the files).Take any number of files, sync/upload them onto your cloud drive.Both computers have MegaSync installed.Share a folder with another contact (not the same account) (= computer X).I can't keep up with keeping the drive organised this way. This has occured maaaaany times and it's starting to be annoying because we have more users to deal with at the moment. I'll try to describe it, since I have no option to log it at the moment. I suggest logging of a trailing time window of 24 hours (so anything older gets deleted). logging still activated after a restart of MegaSync/reboot of OS? Otherwise it will be hard to log this since MegaSync on the second computer, which is incorrectly re-uploading the files deleted on the first computer, is autostarted with the OS and will start uploading instantly after scanning. PS: Is there a way to activate logging permanently, i. I'll try to activate logging daily now and wait until the next occurence. One at its original location (got re-downloaded at the moment MegaSync got started on a second computer) and one at the location I've moved the folder to. The result has been a duplicate of that folder. I've used to think this only happens when I delete/rename a huge number of files, but yesterday, it happened when just moving a folder with a couple of files slightly deeper down the (sub-)folder structure (unfortunately, I hadn't activated logging at that moment). ![]() I'm still unable to produce this on purpose, but similiar to, I've been experiencing this once in a while since I've started using Mega 1 or 2 years ago. Anyway, once you send your report to support, we could contact you directly by email to keep you updated and request additional information if needed. If you can provide additional information (like the name of the file that was incorrectly managed) that would speed up our investigation. If you don't want to share it here (it could contain sensitive data like filenames, etc.), please send it to and post here the ticked ID so we can contact our support team to get your log. Once you have a log showing the problem, please send it to us to analyze it and fix the problem. When the debug mode is correctly started, MEGAsync shows a notification that says that it is creating a log ("MEGAsync.log") in your desktop. To enable de debug mode, start MEGAsync with Ctrl+Shift pressed (Cmd+Shift on OS X), or open the settings dialog and click five times in the shield next to your email address. That way, we could see how the external notification is received, how it is managed by MEGAsync and why it doesn't apply it correctly. ![]() Please create a debug log with Computer B while you are reproducing it. If you are able to reproduce the problem. But once a synchronization is already added (it doesn't matter if MEGAsync is not running or is restarted) MEGAsync should correctly propagate the changes. ![]() During the first scan, if MEGAsync detects missing files, it follows the most conservative approach and creates the missing files on the other side instead of deleting them. MEGAsync should recognize the external deletion (or rename) and apply it in the local filesystem, except when the synchronization is added to MEGAsync. Or maybe cryptomator on Computer B doesn't like that MEGAsync deleted his files at runtime. If those deletions are done in the virtual drive, the real files created by cryptomator could be doing something different and maybe that confuses MEGAsync. The usage of Cryptomator could be changing the scenario a bit. ![]() For us Computer B always removes the local files after the step 4.Īre you using the same account in both computers? Or are you syncing a shared folder in one of them? Hello, we have been trying to reproduce the problem but we have been unable. ![]()
0 Comments
Leave a Reply. |