Call for ALPHA testers for hugely updated MEGAsync 5.0

[mattw-mega]

Hi MEGAsync technical users,

We have been updating the sync algorithm in conjunction with overcoming some internal limitations in the MEGA SDK library. The old sync algorithm and those internal limitations were co-dependent on each other, so it was not possible to update one or the other independently in smaller increments.

At the same time, we have been paying attention to the various issues reported for MEGAsync, and the updates to the sync algorithm include fixes for most of those problems, and enable fixes for the rest.

Because this is such a big update, we would like to invite keen people to try out the updated version before we release it, and report any situations for which the updated version doesn't work for them, or any bugs that they can find. The ways in which MEGAsync can be used is vast and we can't test every combination of all factors ourselves. Consider all the possible OS, filesystem, intentions for initial syncing and ongoing updates, interactions with other changes going on in the filesystem and the MEGA account simultaneously, and so on. Additionally we are introducing the long-promised update for exclusions, via the .megaignore file.

These are the main updates:

• .megaignore file for exclusions.
• Sync logic is now based on what changed since the last time a file was synced.
• This fixes the old problem where you can overwrite a file on the local side of your sync with an older version deliberately, but the sync would download the newer one from the cloud and overwrite that.
• Sync decisions are always based on comparisions of Cloud, Local, and Last synced state, rather than applying lists of changes from cloud and local.
• This enables the sync state to be kept offline, even while the MEGA account changes, which is important for the Suspended state mentioned below.
• Sync problems that are impossible for the sync algorithm to decide by itself are reported to the user in the new Stall Issues window.
• This means that you will now be alerted to things like multiple filenames that would clash when synced, so only one could be synced, or where both local and remote files changed since the sync last ran, and we don't know which is the one you want to keep.
• Sync logic runs on a separate thread, which should make the GUI much more responsive.
• Filesystem scanning and fingerprinting for syncs also runs on a separate thread, should be much quicker, especially on startup with already synced syncs.
• Fetching changes to your account since the last time MEGAsync ran should also be much faster.
• Instead of just Active and Disabled states, we now have Running, Paused, Suspended, Disabled.
• Suspended state is the most significant one. In this one, the last known sync state is kept on the the local disk in a database. Resuming that sync will continue it from where it left off. This is now the default for syncs that are not ticked in the Settings dialog. Previously those were in Disabled state (in which the sync database was deleted).
• This means that the old problems with download of files that were locally deleted while the sync was unticked are solved, when using Suspended state.
• Disabled state is still available for backward compatibility and to be able to easily discard the sync state, make some changes in the Cloud or Locally, and start the sync again from scratch.

We will post installers for Windows and Mac in this thread. They will not be officially signed, as we want to avoid anyone thinking they are anything other than ALPHA versions still under development. Please only use installers posted by myself. Additionally, there is plenty of new text that has not been translated yet. Please only test in ways that do not put your data at risk. As before, the syncs will only move your files and folders to the Rubbish folders when it thinks they should be removed from the sync, so nothing too bad can happen. (One important exception though, is syncs that are set up in an incoming share, where it is not possible to put those Nodes in the Node owner's Rubbish folder).

Details of how .megaignore rules work were posted in this other issue. Please refer there for details, and report questions or bugs specific to .megaignore in that thread: https://github.com/meganz/MEGAsync/issues/206#issuecomment-1143136772

Please also post feedback on any other issues in this thread, and we can iterate until any discovered issues are resolved. thanks

[Perkolator]

• Force a full scan is still present, but on the Syncs tab (and does not require restarting the app anymore). Quick scan just checks directory listings and metadata such as file size and modfied date. Deep scan goes a bit further, checking the actual file data by fingerprinting it again, which is considerably slower (but more accurate).

When does the full scan happen, in what situations? Does it happen every time the client is started, i.e. after reboot of the OS? If it does, it makes syncing big data sets problematic.

[mattw-mega]

Hi @Perkolator, Not every time, and not most of the time. If nothing changed since the last run, the scanning on startup should be fairly efficient - though it's dramatically improved even for that case on Windows, using a windows API that pulls all the data in one go rather than file by file.

The Full Scan button has always been a deep scan (ie, it reads file data, not just the directory entries. Just enough to get the fingerprint, but it's still an expensive operation). That one is only when you request it yourself. However there were various ways in which the GUI layer might cause a similar effect on the next restart. In the current one for example, if you edit exclusions then they don't apply until the next restart, and at that time the sync cache is discarded and everything has to be re-fingerprinted. You may have been encountering that. That case is fixed in the new 5.0 version, and additionally the normal startup scanning (of directory entries only) is much faster too.

So in summary: yes you may have seen excessive slow scanning on startup in the current sync algorithm. The new one is much better behaved.

thanks

[cihe13375]

Just found another little thing. Recently I upgraded to 5.0.9 on another PC, and it complained about some file conflicts on .DS_Store (which is weird because I don't use macOS, and those files are just like "someone using macOS sent me an archive and I decompressed it"; that's another story though). The problem is that, the conflict item doesn't go away after I choose an option. For example, maybe originally it looks like this:

Remote Copy .DS_Store 7KB /path/to/file [Choose]
Local Copy .DS_Store 7KB D:\path\to\file [Choose]

After I choose "Remote Copy" it becomes this:

Remote Copy .DS_Store 7KB /path/to/file [√ Chosen]
Local Copy .DS_Store 50Bytes D:\path\to\file [× Moved to recycle bin]

It seems that this is already resolved. But if I click "refresh" (or reopen the dialog), it reappears again like this:

Remote Copy .DS_Store 7KB /path/to/file [Choose]
Local Copy .DS_Store 50Bytes D:\path\to\file [Choose]

But if I click into the local folder (D:\path\to\file) I can see the local file is already gone. To make those "resolved conflicts" disappear I need to suspend and restart the sync.

[mattw-mega]

hi @cihe13375 , thanks for the testing and for the report. I've been looking into that one and I'm sure we can improve it for the next version. The list is only updated after the sync thread has had a chance to iterate the entire sync, and if it's a large and busy sync then that might take a short while. We can make sure it doesn't show those manually adjusted ones before then though. thanks again

[mattw-mega]

hi @cihe13375 (and others who may be interested), I've made version 5.0.10 available in the first comment above, and it includes the prevention of those Stall items showing up again when you press Refresh, if the sync hasn't gotten around to processing the changes yet. Of course, the general case is that you would make some changes in the local or remote filesystem yourself to resolve an issue, since we can't guess every possible fix for every issue. And then the sync will process those changes, possibly after some short delay if a lot of other things are going on in the sync, so it's hard to be sure when to press Refresh. If your issue does show up again and you did address it, then it probably just needs a bit more time and it should come right shortly. thanks

[MrMechanical]

I am giving the 5.0.10 a spin, and I have encountered an issue.

When I uninstalled 5.0.9 and installed 5.0.10 I got this error in my Mega account:

Thank you for your help.

[MrMechanical]

Ok, the issue fixed itself (it's back to scanning). My apologies for the confusion I am new to Mega, and I am really enjoying the service and its secure encryption technology so far.

[OceanBagel]

I've been trying to use this Alpha version with a Backup sync (currently on 5.0.10) but I've been encountering a strange issue that I don't think is normal... Whenever I modify certain existing local files that are in the folder to be backed up, the modified files are never backed up. Instead, a Sync Issue is added saying that a conflict has been detected between the remote copy and the local copy. This already seems unintended, as I would expect the sync to identify the local file as the newer version and upload it without the user needing to select an option. And this is especially true with a backup, where the remote copy isn't normally able to be modified.

Unfortunately it doesn't end there, as these conflicting copy sync issues cannot be resolved. I choose the Local Copy, it says it's been resolved, but then the file never gets uploaded and the issue never gets cleared from queue. Even after the scan is completed, even after a Deep Rescan, I find myself unable to get these modified files uploaded to the backup.

Another very similar manifestation of this problem is a Name Conflict sync issue. For these issues, it appears that there are two versions of the same file on the remote backup but only one local file. Again I don't really know why this prompt is appearing for a backup sync, and again taking action on the prompt (deleting one of the duplicate remote copies) doesn't actually change anything: files aren't getting uploaded and the sync issues I took action on remain in the sync issues list after refreshing.

I should note that this is only happening on some of the files in the backup folder. Other files seem to upload just fine, but there are about 500 unresolvable sync issues that are preventing certain files from being uploaded.

I do know that there were several initial issues with the backup, where MegaSync would crash repeatedly after some time of uploading the backup. I figured that may have something to do with my current issues, but I would have expected at the very least to be able to manually resolve these issues through the Sync Issues window.

I've attached images of the two different types of sync issues that are preventing certain modified files from being backed up.

[MrMechanical]

I am having the same issue as well.

[mattw-mega]

Hi @OceanBagel and @MrMechanical , thanks very much for testing and reporting those issues with Backup in the Alpha. Those certainly sound like problems that must be addressed, I'll look into it. Do you know if the duplicate named file in the cloud was created by the old system (if you updated MEGAsync and this was a pre-existing Backup) or by this new Alpha? thanks

[MrMechanical]

I did indeed update Megasync in the middle of the backup. I started with 5.0.9 alpha and upgraded to 5.0.10 alpha. Here are the duplicate files shown in Megasync UI. Thank you for your help.

[mattw-mega]

Hi @MrMechanical , thanks for the information. The old sync core did have a problem with sometimes creating duplicates, but then ignored all but one of those when continuing to sync. So, very likely that is how those were caused then. It's great that you bring this up, since for Backups you are disallowed from making cloud changes yourself, and this will likely occur for others too. I'll figure out a way that SRW Backup can correct those without bothering the user. thanks

[Perkolator]

for Backups you are disallowed from making cloud changes yourself

This is the reason I won't ever use your backup feature. You should have studied better ways to implement this, e.g. how SpiderOakONE does it (& their service also has unlimited file versions, unlike your max 100 versions (which doesn't even work properly (I can see versions (with the file) put to recycle bin sometims even though that file is not deleted, only modified)), and they have deduplication, yes, even when all is client-side encrypted).

[MrMechanical]

Hi @MrMechanical , thanks for the information. The old sync core did have a problem with sometimes creating duplicates, but then ignored all but one of those when continuing to sync. So, very likely that is how those were caused then. It's great that you bring this up, since for Backups you are disallowed from making cloud changes yourself, and this will likely occur for others too. I'll figure out a way that SRW Backup can correct those without bothering the user. thanks

Thank you for your help. I was wondering if I restart the backup from the beginning entirely using only 5.0.10, would this duplication issue be avoided? Also, would it be safe to update from the 5.0.10 version (to 5.0.11 when it releases) in the middle of a backup in the future since the issue duplication is only in the 5.0.9 version? Thank you again for your help.

[mattw-mega]

Hi @MrMechanical , yes, I would recommend, using 5.0.10:

• stop the backup and move the backup root folder to your main cloud
• configure the Backup again. It will avoid uploading again for eg. photos, videos etc and instead clone those nodes from the prior backup, to build your new backup more quickly and using less bandwidth.
• you should not see any duplicates
• you should be fine to update to 5.0.11 when it's available, even if the backup is ongoing at that time.
  thanks

[OceanBagel]

The duplicate files were uploaded by the new system for me. I initially tried with the stable released version but the progress was so slow that effectively nothing had uploaded yet. So I deleted what was remaining of the backup and created it again on an alpha version (I believe 5.0.8), where the backup seemed to progress much quicker. Also, some of the files had been created after switching to the alpha version so they wouldn't have been able to be uploaded under the old system.

[OceanBagel]

I just created a different backup outside of the one I already had and it also generated some of these sync issues. It also crashed during the scanning/syncing process, like the other backup. It seems like these duplicate entries only appeared after the crash.

Here's the crash message:

MEGAprivate ERROR DUMP
Application: MEGAsync [64 bit]
Hash: 60e320da6049d6ce57d5d9883a886087
Version code: 5010.0
Timestamp: 1677503220819
Module name: MEGAsync.exe
Operating system: Windows 10.0.19045
Error info:
Unhandled exception 0xC0000005 at 0x0()
Stacktrace:
#0 ----------
#1 ----------
#2 0x25BA1 (ntdll.dll)
#3 0x20000 (ntdll.dll)
#4 ----------
#5 ----------
#6 0x469F93 (MEGAsync.exe)
#7 0x2DE4B9 (MEGAsync.exe)
#8 0x2C6C57 (MEGAsync.exe)
#9 0x2C690E (MEGAsync.exe)
#A 0x2C690E (MEGAsync.exe)
#B 0x2C690E (MEGAsync.exe)
#C 0x2C690E (MEGAsync.exe)
#D 0x2E1DBD (MEGAsync.exe)
#E 0x27BD21 (MEGAsync.exe)
#F 0x21BB2 (ucrtbase.dll)
#10 0x17614 (KERNEL32.DLL)
#11 0x526A1 (ntdll.dll)
------------------------------
MEGAprivate ERROR DUMP
Application: MEGAsync [64 bit]
Hash: 0fbecc014fe388b1964edb8d66526f62
Version code: 5010.0
Timestamp: 1677467124417
Module name: MEGAsync.exe
Operating system: Windows 10.0.19045
Error info:
Unhandled exception 0xC0000005 at 0x26DD03(MEGAsync.exe)
Stacktrace:
#0 0x26DD03 (MEGAsync.exe)
#1 0x471AC0 (MEGAsync.exe)
#2 0x2C6776 (MEGAsync.exe)
#3 0x2C690E (MEGAsync.exe)
#4 0x2C690E (MEGAsync.exe)
#5 0x2C690E (MEGAsync.exe)
#6 0x2C690E (MEGAsync.exe)
#7 0x2C690E (MEGAsync.exe)
#8 0x2C690E (MEGAsync.exe)
#9 0x2E1DBD (MEGAsync.exe)
#A 0x27BD21 (MEGAsync.exe)
#B 0x21BB2 (ucrtbase.dll)
#C 0x17614 (KERNEL32.DLL)
#D 0x526A1 (ntdll.dll)

[MrMechanical]

Unfortunately, I am still experiencing duplicates using only 5.0.10 backup.

Edit: additional operating system reference

[mattw-mega]

Hi @OceanBagel and @MrMechanical , thanks very much for the reports. I've diagnosed the second stack trace and that'll be fixed for the next version (the first is a bit trickier but probably the reason will become apparent over time). And I'll look into the duplicate names, thanks for confirming that does occur in the alpha. I thought I saw that once myself, long ago, but was unable to reproduce it. The clue about it following a crash may be very useful, please let me know if you notice any other unusual condition that may be related or may help to reproduce that. thanks

[cihe13375]

Hi! I'm wondering what performance is expected for adding large number of files to sync. Yesterday I moved a folder of ~170k files to the sync directory, and after ~20 hours the transfer manager still looks like this, with basically no files uploaded already:

Some extra info: 1) the sync directory is in an NTFS partition on an SSD; 2) the "some issues ocurred" in the image above is about ~800 file name conflicts unrelated to the new folder

[mattw-mega]

Hi @cihe13375 , thanks for reporting that. I see the transfer counts on the left indicate it never got as far as queueing more than 12k files when there should have been 170k files. The expected performance is that you should see the Uploads counting up as it scans the folders, until it gets to 170k. I suspect there may have been either some issue with permissions where it couldn't recurse into a folder? Or, perhaps a subfolder or subfolder(s) containing the bulk of the files is ignored due to the .megaignore rules? Or, perhaps some of those name clashes are with such subfolders (though, you said they are unrelated - but, that is a lot to check). Anyway, if you like you could get more clues by checking the log at: C:\Users\<you>\AppData\Local\Mega Limited\MEGAsync\logs\MEGAsync.log. (ignore the ones with numbers, those are older and zipped). You should see lines showing it recursing through your directories, and wherever it fails to go into a folder with all the missing files, you should see a reason why. thanks

[cihe13375]

Thanks for the response. During these two days the # of files in the "uploads" page grows slowly to ~16k --- so I think it's not because some files are excluded, but rather the "scanning" process is too slow for some reason. In the log file there are lots of entries like this (I have replaced actual folder names with a,b,c,d, etc.):

03/13-08:08:35.979965 14212 DTL  Parent cloud folder to upload to doesn't exist yet triplet: (null) /a b/c-d/e/.f.g/h/i.j/k/e044ee1cb6d632c68ce23b8e7eefae7e L:\SyncRoot\a b\c-d\e\.f.g\h\i.j\k\e044ee1cb6d632c68ce23b8e7eefae7e [sync.cpp:8369]

and sometimes with entries like this:

03/13-08:12:36.184199 14212 DTL  Exiting folder with 0-2-2 (0) at /a b/c-d/f [sync.cpp:6918]
03/13-08:12:36.184205 14212 DTL  Entering folder with 0-2-2 (0) at /a b/c-d/e [sync.cpp:6473]
03/13-08:12:36.184252 14212 DTL  Delay creating cloud node until parent cloud node exists: L:\SyncRoot\a b\c-d\e triplet: (null) /a b/c-d/e L:\SyncRoot\a b\c-d\e [sync.cpp:8536]

The megaignore file contains:

-:*.sb-????????-??????
-:desktop.ini
-:Thumbs.db

I don't think that's the reason.

[OceanBagel]

I've also had a buildup of files that had been stalling at the "Completing" state. I think it may have been what contributed to the crashing, as the file count would increase too fast and eventually the transfer manager was flooded with thousands of these files in the completing state. From what I could observe, it seemed like file uploads could not be completed unless the backup finishes scanning. I had a bit more success with alternating pausing the backup and the transfer manager, making sure to leave a bit of time with both on as it seemed like the uploads also could not complete while the backup was paused.

It also seemed like the files marked as "Completing" were actually successfully uploaded as I could find them in the cloud backup.

Another thing I've been noticing is that my backup stops itself automatically on occasion. I don't know what causes it as I haven't seen it as it happened, only after the fact possibly hours later.

[mattw-mega]

Hi @cihe13375, thanks very much for the additional info. It does sound like there is some holdup or problem with folder creation in MEGA for your sync, with the "parent cloud folder doesn't exist yet" lines. Would you mind please, checking the log and search for "Creating cloud node for". Those lines will also name the folder it's trying to create. Can you please see if that recurs over and over for the same folder? There may be quite a few lines in between, but the error reason may be given shortly before a retry.

As to the speed it should be going it - the main test I run has 10k uploads added to the transfer manager every 30 seconds during scanning. Those are very small files that are quickly fingerprinted. Once they have been fingerprinted, that doesn't need to be done again and so on restart and rescan, it can add 10k uploads to the transfer manager every few seconds. So, I think in your case something is going wrong with those folder creations, and that's preventing it from recursing very far into the tree. thanks

[mattw-mega]

Hi @OceanBagel , thanks very much for the additional information, especially that files still showing as "completing" are actually in the cloud. There may be some problem where the GUI side is failing to receive notifications from the transfer subsystem, or some bug in the lookup of them, etc. I will keep an eye out for this, probably that's more to do with the transfer manager than the sync code per se, but I'm sure we can get to the bottom of it, that is a great clue.

As to the backup stopping itself, if you check the Settings window, there should be a yellow warning triangle next to the Backup configuration, and mouse-over that will show a tooltip with the reason it stopped? thanks

[Perkolator]

probably that's more to do with the transfer manager

Transfer manager in the stable version has bugs/inconveniences.

1. Sometimes randomly very small files (when uploaded at the same time with other files) do not appear in the "Completed" section at all. That same thing happens randomly in the "Transfers" section of the systray icon popup too. Something to keep an eye out? Maybe related to the other user problem?
2. The "Avg speed" column info is totally wrong, e.g. completing a 4 GB file transfer, the avg speed says 4 GB/s, even though the upload took 1 hour.
3. Column sort should be remembered & be independent at least between "all transfers" and "completed". Why? It would make more sense to sort "completed" by "time completed" (descending chronological order, latest first) and make that default, but "all transfers" to sort by "status" column by default (so that custom sort order (drag&drop) works properly).
4. Sometimes relatively small files gets put ahead of BIG files and uploaded first (or at the same time if added when a big file is already uploading) but not always. If I'm uploading e.g. a 2 GB file, I'd expect that a mere e.g. 4-10 MB file (or even bigger) would be put ahead of it and uploaded first (or at the same time, like the small files that actually do get priority).

[cihe13375]

Would you mind please, checking the log and search for "Creating cloud node for".

I checked and there's no "Creating cloud node for"; only some "Delay creating cloud node until parent cloud node exists" as shown in my previous post. The latest log file only covers several minutes though (yes the log file size grows fast like that).

side note: the new folder I added contains ~39k subfolders in total (according to windows explorer).

[OceanBagel]

I have a little more information on the issue of lots of "completing" files building up in the transfer manager. I'm able to replicate the issue by pausing the backup while files are in the queue. The files in the queue continue to be uploaded but they remain in the "Completing..." state until the backup is unpaused. It also seemed like the "completing" files do go away over time, it's just that new files are queued and uploaded faster than old files can be cleared out of the "completing" state, so the number of files in the "completing" state builds up over time.

I don't remember what the tooltip said last time the backup stopped, but I'll look out for it next time it happens and let you know.

[mattw-mega]

Hi @cihe13375 , thanks for checking that. Sorry for the delay getting back to you, I've had some urgent other things to look into, but should be back to spending time on this soon. Could you please try locally moving those things that are not synced(backed-up) yet, out of the sync in order to reduce the volume of logging. Hopefully that will allow for finding the problem in the logs. thanks

[mattw-mega]

Hi @OceanBagel , that is actually intentional at the moment - the sync/backup is responsible for final Node creation in the cloud, so that it can deal with possible last second changes in the cloud from other clients (or even other sync actions) that could otherwise result in multiple files with the same name in the same folder. Or files that were moved to other folders while the the upload was going on, etc. So, if the sync is paused, that logic doesn't run, and the transfer stays at 100% but the node to refer to it is not created (until the sync/backup is unpaused). Probably, pausing the sync should also pause all the associated transfers, but that is not the case currently (but is being considered). thanks

[cihe13375]

@mattw-mega I created a new folder with the same directory structure (~39k subfolders, but with all files removed) and let megaSync upload the new folder from scratch. There's a single entry about creating cloud nodes in the logfile:

DTL  Creating cloud node for: L:\SyncRoot\test folder empty as test folder empty triplet: (null) /test folder empty L:\SyncRoot\test folder empty [sync.cpp:8516]

where "test folder empty" is the name of the new folder. After that there're ~1000 entries like this, scattered in the logfile in ~1 hour:

DTL  Create cloud folder already in progress triplet: (null) /test folder empty L:\SyncRoot\test folder empty [sync.cpp:8491]

and I cannot find the folder "test folder empty" (at where it should be) if I log into Mega website in a browser. The rest of logfile is mostly filled with stuff like

DTL  Delay creating cloud node until parent cloud node exists: L:\SyncRoot\test folder empty\................

The situation is somewhat improved if I click "log out" in Settings-Account and restart the client (and recheck those syncs which are automatically disabled). More entries of Creating cloud node for ... appear in the logfile after restart, and more folders appear in the listing on website. But the effort is limited: after ~3k entries of Creating cloud node for ..., "the creation of new cloud node" stopped (i.e. no more such entries in the logfile for a long time); and there're lots of entries like DTL Create cloud folder already in progress triplet: following that. And lots of subfolders are still missing in the website, compared to the local directory structure. It seems that the situation will further improve if I logout and restart multiple times (after two more restarts the client has Creating cloud node for ~16k subfolders), but each restart only provides limited progress. In other words, I can let more subfolders to appear in the website by logout and restarting client again and again, but some subfolders are still missing after several repeats (for each cycle I wait long enough until the client doesn't Creating cloud node for ... anymore for a long time).

Side Notes: 1) the folders I claimed missing in website are not excluded by megaignore; 2) my subscription is still valid and I'm far away from exhausting storage or transfer quota; 3) for some reason clicking "Cloud Drive" in the megaSync GUI doesn't work (I have to manually type in mega.nz in my browser); 4) click "log out" in the client doesn't really log me out (i.e. I don't need to type in username and password after restart, but I need to manually re-enable all syncs); 5) reload my account in browser doesn't help.

[mattw-mega]

hi @cihe13375 , thanks very much for the additional info, and apologies for the delay getting back to you. It does seem to be consistent with some sort of failure to create folders in your MEGA account. What you could look for in the log is the regex cs Send|cs Rec , and see if it is sending the same or similar request to the servers over and over, and possibly getting an error code back (which would just be a negative number in the cs Rec lines). thanks

[cihe13375]

@mattw-mega There're only ~10 matches of cs Send|cs Rec in ~30GB of log file, and I doesn't see any error codes. Some of the cs Rec lines are like this:

cs Received 5: [0,0] (at ds: 17273992) [net.cpp:2324]
cs Received 15: [["GUXksT",[]]] (at ds: 17277039) [net.cpp:2324]
cs Received 479: [{"mstrg": ... (a long list of key-value pairs)

cs Received 8891: [["GUXm?7",[]],["GUXm@v",[]],["GUXmDz",[]],["GUXmG.",[]],["GUXmJ4",[]],["GUXmKd",[]],["GUXmL_",[]],["GUXmMs",[]],["GUXmNJ",[]],["GUXmPq",[]],["GUXmR0",[]],["GUXmT`",[]],["GUXmYe",[]],["GUXm^z",[]],["GUXmcO",[]],["GUXmdl",[]],["GUXmft",[]],["GUXml2",[]],["GUXmp3",[]],["GUXmw=",[]],["GUXm{.",[]],["GUXn#C",[]],["GUXn#|",[]],["GUXn$Q",[]],["GUXn(7",[]],["GUXn*B",[]],["GUXn0h",[]],["GUXn3a",[]],["GUXn4p",[]],["GUXn5s",[]],["GUXn?2",[]],["GUXnAv",[]],["GUXnE-",[]],["GUXnFC",[]],["GUXnJ2",[]],["GUXnR+",[]],["GUXnT(",[]],["GUXnYr",[]],["GUXnZX",[]],["GUXn[s",[]],["GUXn]}",[]],["GUXnbv",[]],["GUXndR",[]],["GUXnf=",[]],["GUXngp",[]],["GUXnk/",[]],["GUXnmW",[]],["GUXnrH",[]],["GUXntM",[]],["GUXnxZ",[]],["GUXn|(",[]],["GUXo o",[]],["GUXo$?",[]],["GUXo)S",[]],["GUXo..",[]],["GUXo1~",[]],["GUXo6@",[]],["GUXo>3",[]],["GUXoA|",[]],["GUXoDz",[]],["GUXoHW",[]],["GUXoJO",[]],["GUXoMM",[]],["GUXoO(",[]],["GUXoS!",[]],["GUXoV3",[]],["GUXoX[",[]],["GUXoY&",[]],["GUXoZ.",[]],["GUXo[N",[]],["GUXo_#",[]],["GUXoc>",[]],["GUXohS",[]],["GUXojU",[]],["GUXoqp",[]],["GUXot.",[]],["GUXoub",[]],["GUXow|",[]],["GUXozR",[]],["GUXo}I",[]],["GUXp!L",[]],["GUXp%q",[]],["GUXp&g",[]],["GUXp'N",[]],["GUXp'}",[]],["GUXp(W",[]],["GUXp)1",[]],["GUXp)u",[]],["GUXp*|",[]],["GUXp-C",[]],["GUXp0s",[]],["GUXp2V",[]],["GUXp3`",[]],["GUXp7]",[]],["GUXp:>",[]],["GUXpBX",[]],["GUXpES",[]],["GUXpH4",[]],["GUXpI{",[]],["GUXpK>",[]],["GUXpLh",[]],["GUXpN8",[]],["GUXpPl",[]],["GUXpSa",[]],["GUXpUO",[]],["GUXpV'",[]],["GUXpVo",[]],["GUXpY:",[]],["GUXpYc",[]],["GUXp[*",[]],["GUXp[~",[]],["GUXp^[",[]],["GUXp`8",[]],["GUXpad",[]],["GUXpbe",[]],["GUXpe`",[]],["GUXphD",[]],["GUXpi4",[]],["GUXpj%",[]],["GUXpk{",[]],["GUXpoI",[]],["GUXpu/",[]],["GUXpv$",[]],["GUXpx8",[]],["GUXp{X",[]],["GUXp~e",[]],["GUXq#d",[]],["GUXq'z",[]],["GUXq+O",[]],["GUXq0T",[]],["GUXq:c",[]],["GUXq< ",[]],["GUXq=u",[]],["GUXq?r",[]],["GUXqA7",[]],["GUXqE%",[]],["GUXqGo",[]],["GUXqK}",[]],["GUXqMo",[]],["GUXqQF",[]],["GUXqQo",[]],["GUXqRa",[]],["GUXqT&",[]],["GUXqUO",[]],["GUXqXE",[]],["GUXq]x",[]],["GUXq^x",[]],["GUXq_j",[]],["GUXq`j",[]],["GUXqcC",[]],["GUXqd+",[]],["GUXqdY",[]],["GUXqe?",[]],["GUXqf)",[]],["GUXqg.",[]],["GUXqhY",[]],["GUXqiN",[]],["GUXqk9",[]],["GUXqm ",[]],["GUXqmf",[]],["GUXqnu",[]],["GUXqoF",[]],["GUXqp'",[]],["GUXqqW",[]],["GUXqrN",[]],["GUXqsO",[]],["GUXqt,",[]],["GUXqtp",[]],["GUXquQ",[]],["GUXqv.",[]],["GUXqvb",[]],["GUXqv{",[]],["GUXqwG",[]],["GUXqwq",[]],["GUXqxg",[]],["GUXqy9",[]],["GUXqz ",[]],["GUXqzr",[]],["GUXq|0",[]],["GUXq}~",[]],["GUXq~y",[]],["GUXr!*",[]],["GUXr#7",[]],["GUXr#o",[]],["GUXr$~",[]],["GUXr&h",[]],["GUXr)J",[]],["GUXr*N",[]],["GUXr+C",[]],["GUXr-'",[]],["GUXr.1",[]],["GUXr.V",[]],["GUXr/'",[]],["GUXr/X",[]],["GUXr1 ",[]],["GUXr2`",[]],["GUXr3z",[]],["GUXr5(",[]],["GUXr8/",[]],["GUXr:,",[]],["GUXr:{",[]],["GUXr<8",[]],["GUXr=y",[]],["GUXr@]",[]],["GUXrAN",[]],["GUXrEu",[]],["GUXrFm",[]],["GUXrIZ",[]],["GUXrKB",[]],["GUXrM%",[]],["GUXrR_",[]],["GUXrUl",[]],["GUXrV:",[]],["GUXrW&",[]],["GUXrXE",[]],["GUXrY_",[]],["GUXr[Z",[]],["GUXr]u",[]],["GUXr`1",[]],["GUXraN",[]],["GUXrbP",[]],["GUXrc+",[]],["GUXrcM",[]],["GUXrcl",[]],["GUXrd@",[]],["GUXrds",[]],["GUXre<",[]],["GUXrfE",[]],["GUXrk/",[]],["GUXrm+",[]],["GUXrmq",[]],["GUXrnt",[]],["GUXrqv",[]],["GUXrt?",[]],["GUXrvn",[]],["GUXrx/",[]],["GUXrxz",[]],["GUXr{i",[]],["GUXr~0",[]],["GUXr~j",[]],["GUXs (",[]],["GUXs ;",[]],["GUXs [",[]],["GUXs t",[]],["GUXs!n",[]],["GUXs$[",[]],["GUXs%V",[]],["GUXs&a",[]],["GUXs(-",[]],["GUXs*q",[]],["GUXs,S",[]],["GUXs/ ",[]],["GUXs1h",[]],["GUXs46",[]],["GUXs7+",[]],["GUXs;*",[]],["GUXs=D",[]],["GUXs@F",[]],["GUXsBF",[]],["GUXsCz",[]],["GUXsJ#",[]],["GUXsKl",[]],["GUXsMA",[]],["GUXsMk",[]],["GUXsPh",[]],["GUXsS]",[]],["GUXsU}",[]],["GUXsY4",[]],["GUXsZ?",[]],["GUXs[%",[]],["GUXs]%",[]],["GUXs]`",[]],["GUXs^6",[]],["GUXs^d",[]],["GUXs_U",[]],["GUXs`,",[]],["GUXs`a",[]],["GUXsaY",[]],["GUXsb:",[]],["GUXsf.",[]],["GUXsjf",[]],["GUXsl>",[]],["GUXsm4",[]],["GUXspi",[]],["GUXst ",[]],["GUXsuO",[]],["GUXsz9",[]],["GUXs}m",[]],["GUXt!_",[]],["GUXt(.",[]],["GUXt+@",[]],["GUXt.Q",[]],["GUXt1z",[]],["GUXt2Q",[]],["GUXt3%",[]],["GUXt4_",[]],["GUXt5-",[]],["GUXt5y",[]],["GUXt:M",[]],["GUXt<V",[]],["GUXt>h",[]],["GUXtA@",[]],["GUXtK*",[]],["GUXtLd",[]],["GUXtOt",[]],["GUXtQO",[]],["GUXtS$",[]],["GUXtT/",[]],["GUXtTd",[]],["GUXtUs",[]],["GUXtVb",[]],["GUXtW:",[]],["GUXtZ5",[]],["GUXt[R",[]],["GUXt_8",[]],["GUXtbo",[]],["GUXtd(",[]],["GUXte8",[]],["GUXtfS",[]],["GUXtkx",[]],["GUXtm+",[]],["GUXtnx",[]],["GUXto}",[]],["GUXtq`",[]],["GUXtz;",[]],["GUXt{+",[]],["GUXt{W",[]],["GUXt|m",[]],["GUXt}D",[]],["GUXt}x",[]],["GUXu p",[]],["GUXu%{",[]],["GUXu&g",[]],["GUXu,>",[]],["GUXu0~",[]],["GUXu3U",[]],["GUXu4W",[]],["GUXu;<",[]],["GUXu>^",[]],["GUXu>|",[]],["GUXu?Z",[]],["GUXuAo",[]],["GUXuB<",[]],["GUXuCg",[]],["GUXuDA",[]],["GUXuKH",[]],["GUXuN;",[]],["GUXuOE",[]],["GUXuZM",[]],["GUXub%",[]],["GUXufG",[]],["GUXuh=",[]],["GUXuj<",[]],["GUXuma",[]],["GUXurx",[]],["GUXuue",[]],["GUXuvt",[]],["GUXv +",[]],["GUXv `",[]],["GUXv!I",[]],["GUXv#S",[]],["GUXv$d",[]],["GUXv%Q",[]],["GUXv&r",[]],["GUXv(=",[]],["GUXv,~",[]],["GUXv-a",[]],["GUXv.P",[]],["GUXv.w",[]],["GUXv/6",[]],["GUXv0L",[]],["GUXv1{",[]],["GUXv3z",[]],["GUXv;-",[]],["GUXv?u",[]],["GUXvAk",[]],["GUXvBS",[]],["GUXvC(",[]],["GUXvCx",[]],["GUXvD9",[]],["GUXvD`",[]],["GUXvE*",[]],["GUXvG4",[]],["GUXvH6",[]],["GUXvJ/",[]],["GUXvLQ",[]],["GUXvMz",[]],["GUXvP9",[]],["GUXvP~",[]],["GUXvQT",[]],["GUXvRm",[]],["GUXvT.",[]],["GUXvTn",[]],["GUXv[Z",[]],["GUXvdn",[]],["GUXvgK",[]],["GUXviw",[]],["GUXvjw",[]],["GUXvk~",[]],["GUXvm]",[]],["GUXvn<",[]],["GUXvoK",[]],["GUXvr7",[]],["GUXvuY",[]],["GUXv{`",[]],["GUXv}5",[]],["GUXv}b",[]],["GUXv~G",[]],["GUXw H",[]],["GUXw%i",[]],["GUXw'/",[]],["GUXw(`",[]],["GUXw)h",[]],["GUXw-/",[]],["GUXw0^",[]],["GUXw40",[]],["GUXw5 ",[]],["GUXw6H",[]],["GUXw7N",[]],["GUXw:#",[]],["GUXw>4",[]],["GUXwAz",[]],["GUXwD?",[]],["GUXwI>",[]],["GUXwLW",[]],["GUXwNG",[]],["GUXwOx",[]],["GUXwP{",[]],["GUXwQx",[]],["GUXwTj",[]],["GUXwWn",[]],["GUXwbS",[]],["GUXweT",[]],["GUXwm-",[]],["GUXwo ",[]],["GUXwoi",[]],["GUXwp`",[]],["GUXwqS",[]],["GUXws,",[]],["GUXwt5",[]],["GUXwv-",[]],["GUXwvF",[]],["GUXwv_",[]],["GUXwwx",[]],["GUXwxv",[]],["GUXw|d",[]],["GUXw}g",[]],["GUXx!k",[]],["GUXx'm",[]],["GUXx)>",[]],["GUXx)~",[]],["GUXx+v",[]],["GUXx1c",[]],["GUXx4S",[]],["GUXx5|",[]],["GUXx9M",[]],["GUXx;,",[]],["GUXx>D",[]],["GUXx@r",[]],["GUXxAX",[]],["GUXxB+",[]],["GUXxCz",[]],["GUXxD_",[]],["GUXxH.",[]],["GUXxJn",[]],["GUXxNj",[]],["GUXxPU",[]],["GUXxR0",[]],["GUXxSA",[]],["GUXxY4",[]],["GUXxZd",[]],["GUXx]3",[]],["GUXx^A",[]],["GUXx_6",[]],["GUXxaN",[]],["GUXxeK",[]],["GUXxf{",[]],["GUXxi*",[]],["GUXxom",[]],["GUXxv>",[]],["GUXxwc",[]],["GUXxz:",[]],["GUXx|E",[]],["GUXy#f",[]],["GUXy%Q",[]],["GUXy):",[]],["GUXy,C",[]],["GUXy-s",[]],["GUXy4 ",[]],["GUXy:@",[]],["GUXy>o",[]],["GUXyA2",[]],["GUXyBa",[]],["GUXyFz",[]],["GUXyI0",[]],["GUXyI}",[]],["GUXyK,",[]],["GUXyN'",[]],["GUXyPW",[]],["GUXyUJ",[]],["GUXyXJ",[]],["GUXyY/",[]],["GUXy[ ",[]],["GUXy].",[]],["GUXy_]",[]],["GUXydE",[]],["GUXydx",[]],["GUXygu",[]],["GUXyk)",[]],["GUXyo6",[]],["GUXys!",[]],["GUXy|k",[]],["GUXz y",[]],["GUXz#2",[]],["GUXz$b",[]],["GUXz('",[]],["GUXz.(",[]],["GUXz00",[]],["GUXz0p",[]],["GUXz45",[]],["GUXz4l",[]],["GUXz8J",[]],["GUXz:5",[]],["GUXz<9",[]],["GUXz=e",[]],["GUXz?1",[]],["GUXzFO",[]],["GUXzG8",[]],["GUXzH:",[]],["GUXzHx",[]],["GUXzIc",[]],["GUXzJO",[]],["GUXzL?",[]],["GUXzMf",[]],["GUXzQa",[]],["GUXzU.",[]],["GUXzX-",[]],["GUXzYz",[]],["GUXz]+",[]],["GUXz_'",[]],["GUXz_P",[]],["GUXz`2",[]],["GUXza;",[]],["GUXzc2",[]],["GUXzh]",[]],["GUXzj!",[]],["GUXzln",[]],["GUXznv",[]],["GUXzpX",[]],["GUXzqC",[]],["GUXzr8",[]],["GUXzs!",[]],["GUXzu'",[]],["GUXzu{",[]],["GUXzw'",[]],["GUXzxG",[]],["GUXz}Y",[]],["GUXz~i",[]],["GUX{!F",[]],["GUX{'<",[]],["GUX{(<",[]],["GUX{)6",[]],["GUX{*#",[]],["GUX{+ ",[]],["GUX{0U",[]],["GUX{2@",[]],["GUX{3X",[]],["GUX{5.",[]],["GUX{6o",[]],["GUX{@D",[]],["GUX{A4",[]],["GUX{DN",[]],["GUX{H*",[]],["GUX{JA",[]],["GUX{M@",[]],["GUX{Pg",[]],["GUX{T4",[]],["GUX{TN",[]],["GUX{VK",[]],["GUX{Y<",[]],["GUX{Zm",[]],["GUX{]m",[]],["GUX{`x",[]],["GUX{cj",[]],["GUX{d?",[]],["GUX{e'",[]],["GUX{h,",[]],["GUX{i9",[]],["GUX{jx",[]],["GUX{k~",[]],["GUX{m5",[]],["GUX{n%",[]],["GUX{n}",[]],["GUX{p&",[]],["GUX{qS",[]],["GUX{rn",[]],["GUX{u!",[]],["GUX{vk",[]],["GUX{}5",[]],["GUX{~/",[]],["GUX| K",[]],["GUX|!g",[]],["GUX|#*",[]],["GUX|#S",[]],["GUX|$.",[]],["GUX|%=",[]],["GUX|'o",[]],["GUX|(f",[]],["GUX|,*",[]],["GUX|,S",[]],["GUX|,~",[]],["GUX|-I",[]],["GUX|/n",[]],["GUX|0@",[]],["GUX|0[",[]],["GUX|4~",[]],["GUX|6.",[]],["GUX|7<",[]],["GUX|8|",[]],["GUX|<]",[]],["GUX|=.",[]],["GUX|>D",[]],["GUX|?'",[]],["GUX|?]",[]],["GUX|D;",[]],["GUX|ES",[]],["GUX|Fb",[]],["GUX|G@",[]],["GUX|Hr",[]],["GUX|JC",[]],["GUX|LE",[]],["GUX|M<",[]],["GUX|Mw",[]],["GUX|O^",[]],["GUX|Pl",[]]] (at ds: 17277500) [net.cpp:2324]
st tag GUXm?7 matched [megaclient.cpp:5221]
st tag GUXm@v processing for GUXm?7 [megaclient.cpp:5228]
...

Create cloud folder already in progress triplet: ... 
cs Received 140001: [["GUY#.W",[]],["GUY#0!",[]],["GUY#13",[]],["GUY#1v",[]],["GUY#3I",[]],["GUY#45",[]],["GUY#4f",[]],["GUY#52",[]],["GUY#5a",[]],["GUY#7b",[]],["GUY#8w",[]],["GUY#:*",[]],["GUY#;B",[]],["GUY#<j",[]],["GUY#>J",[]],["GUY#?d",[]],["GUY#A$",[]],["GUY#Bp",[]],["GUY#E@",[]],["GUY#FN",[]],["GUY#I1",[]],["GUY#M#",[]],["GUY#OO",[]],["GUY#Q=",[]],["GUY#S3",[]],["GUY#U}",[]],["GUY#ZA",[]],["GUY#[G",[]],["GUY#]U",[]],["GUY#_B",[]],["GUY#`t",[]],["GUY#cd",[]],["GUY#gy",[]],["GUY#h}",[]],["GUY#jJ",[]],["GUY#l9",[]],["GUY#sS",[]],["GUY#wn",[]],["GUY#yd",[]],["GUY#{<",[]],["GUY#}%",[]],["GUY$ 7",[]],["GUY$!}",[]],["GUY$%;",[]],["GUY$(c",[]],["GUY$*b",[]],["GUY$,.",[]],["GUY$.d",[]],["GUY$3c",[]],["GUY$4D",[]],["GUY$5l",[]],["GUY$7{",[]],["GUY$9i",[]],["GUY$<q",[]],["GUY$Au",[]],["GUY$Df",[]],["GUY$G,",[]],["GUY$I%",[]],["GUY$Jl",[]],["GUY$Lt",[]],["GUY$S9",[]],["GUY$W=",[]],["GUY$Xh",[]],["GUY$[)",[]],["GUY$]k",[]],["GUY$^B",[]],["GUY$_;",[]],["GUY$`K",[]],["GUY$aS",[]],["GUY$c6",[]],["GUY$e:",[]],["GUY$fG",[]],["GUY$g^",[]],["GUY$hK",[]],["GUY$i@",[]],["GUY$in",[]],["GUY$jH",[]],["GUY$kM",[]],["GUY$lP",[]],["GUY$pv",[]],["GUY$s6",[]],["GUY$ue",[]],["GUY$xT",[]],["GUY${B",[]],["GUY$}L",[]],["GUY%#5",[]],["GUY%$L",[]],["GUY%&;",[]],["GUY%,]",[]],["GUY%-*",[]],["GUY%-z",[]],["GUY%.U",[]],["GUY%/,",[]],["GUY%/w",[]],["GUY%0D",[]],["GUY%2Y",[]],["GUY%3I",[]],["GUY%42",[]],["GUY%4k",[]],["GUY%6@",[]],["GUY%6b",[]],["GUY%71",[]],["GUY%86",[]],["GUY%9-",[]],["GUY%9m",[]],["GUY%<E",[]],["GUY%<y",[]],["GUY%?x",[]],["GUY%@4",[]],["GUY%@t",[]],["GUY%C;",[]],["GUY%Cl",[]],["GUY%DQ",[]],["GUY%F>",[]],["GUY%Ho",[]],["GUY%I`",[]],["GUY%Jh",[]],["GUY%K4",[]],["GUY%Lb",[]],["GUY%N>",[]],["GUY%Ns",[]],["GUY%Q=",[]],["GUY%R6",[]],["GUY%We",[]],["GUY%Yu",[]],["GUY%]5",[]],["GUY%^S",[]],["GUY%_;",[]],["GUY%`U",[]],["GUY%a9",[]],["GUY%ag",[]],["GUY%bF",[]],["GUY%bj",[]],["GUY%c5",[]],["GUY%c{",[]],["GUY%e$",[]],["GUY%f'",[]],["GUY%fu",[]],["GUY%h5",[]],["GUY%lb",[]],["GUY%n|",[]],["GUY%pa",[]],["GUY%r~",[]],["GUY%s{",[]],["GUY%u=",[]],["GUY%v;",[]],["GUY%vk",[]],["GUY%xR",[]],["GUY%yN",[]],["GUY%{W",[]],["GUY%|T",[]],["GUY%~Y",[]],["GUY&!,",[]],["GUY&#!",[]],["GUY&$/",[]],["GUY&%c",[]],["GUY&(7",[]],["GUY&,X",[]],["GUY&.;",[]],["GUY&26",[]],["GUY&5%",[]],["GUY&8j",[]],["GUY&9]",[]],["GUY&;F",[]],["GUY&=5",[]],["GUY&?_",[]],["GUY&@T",[]],["GUY&E2",[]],["GUY&E{",[]],["GUY&Fh",[]],["GUY&GO",[]],["GUY&J'",[]],["GUY&N=",[]],["GUY&Nc",[]],["GUY&OS",[]],["GUY&QH",[]],["GUY&Sg",[]],["GUY&V1",[]],["GUY&Vv",[]],["GUY&X=",[]],["GUY&Xi",[]],["GUY&Z@",[]],["GUY&Zk",[]],["GUY&]j",[]],["GUY&^A",[]],["GUY&^]",[]],["GUY&_.",[]],["GUY&`Q",[]],["GUY&`x",[]],["GUY&bS",[]],["GUY&br",[]],["GUY&cW",[]],["GUY&f*",[]],["GUY&g!",[]],["GUY&hc",[]],["GUY&m ",[]],["GUY&o(",[]],["GUY&px",[]],["GUY&r8",[]],["GUY&st",[]],["GUY&{z",[]],["GUY' G",[]],["GUY'&X",[]],["GUY''Z",[]],["GUY'(Y",[]],["GUY',|",[]],["GUY'-D",[]],["GUY'-h",[]],["GUY'.l",[]],["GUY'6,",[]],["GUY';B",[]],["GUY'=k",[]],["GUY'>m",[]],["GUY'C&",[]],["GUY'CE",[]],["GUY'E9",[]],["GUY'FR",[]],["GUY'Hb",[]],["GUY'I3",[]],["GUY'IO",[]],["GUY'JF",[]],["GUY'Md",[]],["GUY'S`",[]],["GUY'Uc",[]],["GUY'W0",[]],["GUY'Xg",[]],["GUY'[;",[]],["GUY'_0",[]],["GUY'as",[]],["GUY'e6",[]],["GUY'hU",[]],["GUY'l(",[]],["GUY'rz",[]],["GUY'uV",[]],["GUY'{1",[]],["GUY'~1",[]],["GUY'~t",[]],["GUY( u",[]],["GUY($:",[]],["GUY()s",[]],["GUY(0#",[]],["GUY(3u",[]],["GUY(5U",[]],["GUY(7@",[]],["GUY(8?",[]],["GUY(9/",[]],["GUY(:J",[]],["GUY(;$",[]],["GUY(<C",[]],["GUY(?O",[]],["GUY(A^",[]],["GUY(B(",[]],["GUY(Bv",[]],["GUY(CV",[]],["GUY(D_",[]],["GUY(F3",[]],["GUY(Gl",[]],["GUY(IZ",[]],["GUY(J.",[]],["GUY(Kd",[]],["GUY(L>",[]],["GUY(Lh",[]],["GUY(O5",[]],["GUY(PF",[]],["GUY(Q;",[]],["GUY(Qo",[]],["GUY(TE",[]],["GUY(WM",[]],["GUY(Y@",[]],["GUY(]b",[]],["GUY(bu",[]],["GUY(dF",[]],["GUY(e<",[]],["GUY(h*",[]],["GUY(j%",[]],["GUY(o9",[]],["GUY(|(",[]],["GUY) 1",[]],["GUY)#]",[]],["GUY)%V",[]],["GUY)(0",[]],["GUY)*+",[]],["GUY),d",[]],["GUY)1!",[]],["GUY)30",[]],["GUY)7.",[]],["GUY)8B",[]],["GUY);J",[]],["GUY)<'",[]],["GUY)<^",[]],["GUY)?i",[]],["GUY)@n",[]],["GUY)BS",[]],["GUY)EY",[]],["GUY)Fh",[]],["GUY)G&",[]],["GUY)G[",[]],["GUY)H-",[]],["GUY)HY",[]],["GUY)J6",[]],["GUY)K8",[]],["GUY)KY",[]],["GUY)M7",[]],["GUY)Ns",[]],["GUY)Pj",[]],["GUY)R?",[]],["GUY)Yj",[]],["GUY)ZV",[]],["GUY)]/",[]],["GUY)^I",[]],["GUY)_q",[]],["GUY)a#",[]],["GUY)c+",[]],["GUY)gA",[]],["GUY)gx",[]],["GUY)k-",[]],["GUY)ko",[]],["GUY)lr",[]],["GUY)mR",[]],["GUY)ng",[]],["GUY)pI",[]],["GUY)q?",[]],["GUY)re",[]],["GUY)sd",[]],["GUY)tn",[]],["GUY)uV",[]],["GUY)wP",[]],["GUY)zb",[]],["GUY)~^",[]],["GUY* s",[]],["GUY*$i",[]],["GUY*&*",[]],["GUY*'5",[]],["GUY*(i",[]],["GUY*)}",[]],["GUY*+R",[]],["GUY*,K",[]],["GUY*.m",[]],["GUY*0!",[]],["GUY*2E",[]],["GUY*3N",[]],["GUY*5X",[]],["GUY*8[",[]],["GUY*9>",[]],["GUY*</",[]],["GUY*=[",[]],["GUY*>k",[]],["GUY*@F",[]],["GUY*Fq",[]],["GUY*Gt",[]],["GUY*I!",[]],["GUY*K^",[]],["GUY*M#",[]],["GUY*Ng",[]],["GUY*R#",[]],["GUY*TE",[]],["GUY*V>",[]],["GUY*Z;",[]],["GUY*b4",[]],["GUY*cO",[]],["GUY*dq",[]],["GUY*ee",[]],["GUY*f>",[]],["GUY*g$",[]],["GUY*k'",[]],["GUY*ku" [...] [f-1",[]],["GU[f-O",[]],["GU[f.&",[]],["GU[f.u",[]],["GU[f2h",[]],["GU[f3^",[]],["GU[f4X",[]],["GU[f5N",[]],["GU[f7J",[]],["GU[f8J",[]],["GU[f:0",[]],["GU[f=+",[]],["GU[f?W",[]],["GU[fAk",[]],["GU[fE6",[]],["GU[fG+",[]],["GU[fI%",[]],["GU[fKz",[]],["GU[fNj",[]],["GU[fS>",[]],["GU[fUE",[]],["GU[fWy",[]],["GU[fX~",[]],["GU[fZZ",[]],["GU[f[5",[]],["GU[f_D",[]],["GU[faG",[]],["GU[fbB",[]],["GU[fd-",[]],["GU[fgi",[]],["GU[fj1",[]],["GU[fl#",[]],["GU[fmT",[]],["GU[fpX",[]],["GU[fr:",[]],["GU[ftT",[]],["GU[fw-",[]],["GU[fz6",[]],["GU[g#%",[]],["GU[g&O",[]],["GU[g/m",[]],["GU[g4n",[]],["GU[g=K",[]],["GU[gFQ",[]],["GU[gI+",[]],["GU[gK}",[]],["GU[gR)",[]],["GU[gTu",[]],["GU[gV!",[]],["GU[gW(",[]],["GU[gZh",[]],["GU[g^s",[]],["GU[gbx",[]],["GU[gg=",[]],["GU[giv",[]],["GU[gl9",[]],["GU[guI",[]],["GU[gyP",[]],["GU[gz-",[]],["GU[g}W",[]],["GU[g~)",[]],["GU[h d",[]],["GU[h$7",[]],["GU[h(T",[]],["GU[h+*",[]],["GU[h.F",[]],["GU[h4 ",[]],["GU[h5U",[]],["GU[h9v",[]],["GU[h>I",[]],["GU[hA_",[]],["GU[hEe",[]],["GU[hI1",[]],["GU[hL{",[]],["GU[hPp",[]],["GU[hR?",[]],["GU[hXG",[]],["GU[hY9",[]],["GU[h[P",[]],["GU[h`f",[]],["GU[hfj",[]],["GU[hhB",[]],["GU[hk5",[]],["GU[hlg",[]],["GU[ho7",[]],["GU[hr&",[]],["GU[hsE",[]],["GU[hwE",[]],["GU[h|G",[]],["GU[i!G",[]],["GU[i$|",[]],["GU[i*T",[]],["GU[i+u",[]],["GU[i,<",[]],["GU[i0z",[]],["GU[i2y",[]],["GU[i6;",[]],["GU[i7o",[]],["GU[i8a",[]],["GU[i:?",[]],["GU[i>>",[]],["GU[i@*",[]],["GU[iAo",[]],["GU[iEZ",[]],["GU[iGb",[]],["GU[iHi",[]],["GU[iL(",[]],["GU[iL]",[]],["GU[iNu",[]],["GU[iP/",[]],["GU[iR,",[]],["GU[iUV",[]],["GU[iVF",[]],["GU[iW9",[]],["GU[iX9",[]],["GU[iY1",[]],["GU[iZ;",[]],["GU[iZm",[]],["GU[i[P",[]],["GU[i[z",[]],["GU[i^M",[]],["GU[i_K",[]],["GU[iaG",[]],["GU[icT",[]],["GU[ie#",[]],["GU[ij:",[]],["GU[ilu",[]],["GU[ip*",[]],["GU[is*",[]],["GU[iv,",[]],["GU[iyF",[]],["GU[i~$",[]],["GU[j*T",[]],["GU[j+o",[]],["GU[j0l",[]],["GU[j3S",[]],["GU[j68",[]],["GU[jA1",[]],["GU[jHo",[]],["GU[jJd",[]],["GU[jKd",[]],["GU[jM;",[]],["GU[jOp",[]],["GU[jRl",[]],["GU[jUF",[]],["GU[jWk",[]],["GU[jXO",[]],["GU[j_2",[]],["GU[jb,",[]],["GU[jj%",[]],["GU[jo/",[]],["GU[ju@",[]],["GU[j|:",[]],["GU[j~w",[]],["GU[k$;",[]],["GU[k*V",[]],["GU[k0_",[]],["GU[k3M",[]],["GU[k4i",[]],["GU[k7l",[]],["GU[k=c",[]],["GU[k?n",[]],["GU[kB$",[]],["GU[kFq",[]],["GU[kKp",[]],["GU[kR`",[]],["GU[kU(",[]],["GU[kUG",[]],["GU[k[I",[]],["GU[kcv",[]],["GU[kd{",[]],["GU[kf)",[]],["GU[kg*",[]],["GU[kif",[]],["GU[kk:",[]],["GU[kls",[]],["GU[kno",[]],["GU[kx5",[]],["GU[ky5",[]],["GU[k}4",[]],["GU[k~6",[]],["GU[l s",[]],["GU[l#v",[]],["GU[l$a",[]],["GU[l&I",[]],["GU[l(u",[]],["GU[l+9",[]],["GU[l/T",[]],["GU[l1^",[]],["GU[l3T",[]],["GU[l4f",[]],["GU[l65",[]],["GU[l7Z",[]],["GU[l9p",[]],["GU[l;>",[]],["GU[l=:",[]],["GU[l?M",[]],["GU[lCG",[]],["GU[lHi",[]],["GU[lIF",[]],["GU[lIw",[]],["GU[lJb",[]],["GU[lK6",[]],["GU[lKx",[]],["GU[lLo",[]],["GU[lN4",[]],["GU[lOt",[]],["GU[lQm",[]],["GU[lS8",[]],["GU[lVR",[]],["GU[lYh",[]],["GU[l[P",[]],["GU[l_/",[]],["GU[l`L",[]],["GU[lb*",[]],["GU[lfx",[]],["GU[lkA",[]],["GU[lq)",[]],["GU[lt'",[]],["GU[lv6",[]],["GU[lw'",[]],["GU[lza",[]],["GU[l{e",[]],["GU[l|d",[]],["GU[l~E",[]],["GU[m |",[]],["GU[m$t",[]],["GU[m&i",[]],["GU[m-f",[]],["GU[m.w",[]],["GU[m/{",[]],["GU[m0L",[]],["GU[m3,",[]],["GU[m8D",[]],["GU[m9;",[]],["GU[m<1",[]],["GU[m?2",[]],["GU[mA]",[]],["GU[mBz",[]],["GU[mE ",[]],["GU[mEu",[]],["GU[mGH",[]],["GU[mI;",[]],["GU[mKw",[]],["GU[mMY",[]],["GU[mN8",[]],["GU[mNr",[]],["GU[mPL",[]],["GU[mQ?",[]],["GU[mRj",[]],["GU[mWQ",[]],["GU[mXj",[]],["GU[mYt",[]],["GU[m[!",[]],["GU[m[U",[]],["GU[m](",[]],["GU[m]I",[]],["GU[m_!",[]],["GU[m_w",[]],["GU[maN",[]],["GU[mbE",[]],["GU[mc7",[]],["GU[mc^",[]],["GU[md:",[]],["GU[me(",[]],["GU[meA",[]],["GU[mf5",[]],["GU[mgu",[]],["GU[mj7",[]],["GU[mk ",[]],["GU[mkl",[]],["GU[mlB",[]],["GU[mn8",[]],["GU[mn]",[]],["GU[mo+",[]],["GU[mp1",[]],["GU[mrQ",[]],["GU[msg",[]],["GU[mtu",[]],["GU[mum",[]],["GU[mw:",[]],["GU[mxa",[]],["GU[mz^",[]],["GU[m|s",[]],["GU[n$C",[]],["GU[n%q",[]],["GU[n(A",[]],["GU[n0,",[]],["GU[n3T",[]],["GU[n7!",[]],["GU[n:>",[]],["GU[n?A",[]],["GU[nC.",[]],["GU[nF'",[]],["GU[nHk",[]],["GU[nN`",[]],["GU[nO(",[]],["GU[nPI",[]],["GU[nQW",[]],["GU[nTd",[]],["GU[nX3",[]],["GU[nZA",[]],["GU[n_w",[]],["GU[ncX",[]],["GU[nf!",[]],["GU[ng|",[]],["GU[niE",[]],["GU[nj]",[]],["GU[nqa",[]],["GU[ny7",[]],["GU[n|e",[]],["GU[n~R",[]],["GU[o!!",[]],["GU[o'#",[]],["GU[o*j",[]],["GU[o0=",[]],["GU[o4G",[]],["GU[o:J",[]],["GU[o>i",[]],["GU[oAC",[]],["GU[oE)",[]],["GU[oI?",[]],["GU[oLD",[]],["GU[oSv",[]],["GU[oX1",[]],["GU[oYB",[]],["GU[oZe",[]],["GU[o^S",[]],["GU[oco",[]],["GU[ogm",[]],["GU[oj?",[]],["GU[ol?",[]],["GU[op1",[]],["GU[osl",[]],["GU[ov/",[]],["GU[p!J",[]],["GU[p&#",[]],["GU[p&R",[]],["GU[p-B",[]],["GU[p/8",[]],["GU[p0i",[]],["GU[p4z",[]],["GU[p7 ",[]],["GU[p:3",[]],["GU[p<b",[]],["GU[p?<",[]],["GU[pEB",[]],["GU[pI]",[]],["GU[pKa",[]],["GU[pMV",[]],["GU[pP}",[]],["GU[pQQ",[]],["GU[pRG",[]],["GU[pS3",[]],["GU[pTY",[]],["GU[pUO",[]],["GU[pVJ",[]],["GU[pW ",[]],["GU[pX6",[]],["GU[pZ^",[]],["GU[p_S",[]],["GU[pb;",[]],["GU[pf0",[]],["GU[plg",[]],["GU[pn8",[]],["GU[pul",[]]] [net.cpp:2329]
Create cloud folder already in progress triplet: ...

Note: I have already "resolved" this issue by logout and restart for ~7 times, and I don't really want to debug this anymore... hopefully you can reproduce it :)

[donnje]

why was the possibility to exclude files and folders from sync removed?

[mattw-mega]

Hi @donnje , that is not removed but rather the rules live in a file in your sync now: .megaignore files which go in the root of your sync (and optionally in other folders in your sync tree also), and contain the exclusion rules. You can read more about that in the first post above. We will add some info to the Settings dialog tab where those rules used to be, to direct users to the new (and better) system. Apologies for not already adding that. thanks

[donnje]

Hi @donnje , that is not removed but rather the rules live in a file in your sync now: .megaignore files which go in the root of your sync (and optionally in other folders in your sync tree also), and contain the exclusion rules. You can read more about that in the first post above. We will add some info to the Settings dialog tab where those rules used to be, to direct users to the new (and better) system. Apologies for not already adding that. thanks

sorry but I didn't understand very well

[sawft99]

I don't know if this is specific to the new alpha or if it's maybe just a windows thing. But I noticed If I create a folder and immediately rename it that I have that folder and one named "New Folder". It's not consistent.

[stalker780]

4.9.1 was freezing last few weeks, so I decided to try alpha.

5.0.10 works much faster with lower CPU consumption in Windows 10.

But when migrating I had to clear all my folders in the cloud and synced PCs. Because I have got about 9000 warnings "Name conflicts". It is a challenge to sort this out manually. 💡 Perhaps there should be an interface button "Use this action for all such conflicts".

1. Copied my synced folders in a separate backup folder on my PC
2. Cleared all synced folders both on all PCs and Mega cloud
3. Prepared .megaignore files in empty folders for my projects
4. Restored backup files to synced folders
5. Waited for synchronization

This took about 5 hours. But now it works like a charm 👌 Thank you Mega for you work!

💡 Another idea for the future: I noticed that Mega works very slowly when projects contain thousands of small files. In my situation these are 14 PHP/HTML/JS projects. They contain about 200000 files 6Gb total. This takes many hours to sync them when I need to sync the whole project. While one big file with a size of 500Mb is synced almost instantly. 12 files with size of 500Mb are synced in 10 minutes. While 200000 files with same total size are synced in 5-6 hours. Perhaps It would be faster if MEGASync could check a quantity of files in a queue and if there is more than 100 files to transfer, it would group/pack/zip them and send as several big files to a server and then unpack to predefined destinations on Mega server. It is just an idea. I can miss something, I don't know the process under the hood, and possibly this time is taken by comparing local and cloud files md5/date/size.

[vaoan]

I had to stop trying the beta because of the warnings. Trying it was taking me way too long with the warnings when syncing with different computers. Until this is fixed I can't use the new alpha.

[stalker780]

Just a minor proposal:

Add webp image icon to makes things just perfect :) It is a popular image format nowadays.

[itayasaf1990xd]

It is not a bug but for the love of god, please make MegaSync UI/UX more streamlined (identical) to Windows 11 Fluent Design Icons/Elements

[mattw-mega]

Hi MEGAsync Alpha Testers, apologies for the large gap. 5.0.15 is now available, link in the first comment above. It contains many improvements, and all the other mainline features that have been added to the production MEGAsync over the last while, as well as bug fixes and improvements from our internal testing.

In particular, @cihe13375: the cloud folder creation you encountered is fixed. @sawft99 : the race condition with creating and renaming a folder is fixed (very lucky/specific timing relative to disk and roundtrip api request time required for that one).

@stalker780 and @GunB , thanks for the info about so many name clashes. We have encountered this internally too, and will be working out a way to help with that. For very long-lived syncs, those can have built up over time as the original system did not notice those.

thanks

[cihe13375]

Glad to see the update after a long time! Is there any chance to get a Linux build (I'm on kubuntu 22.04)? Btw, I'm wondering what's the best practice to use megaSync on a Windows/Linux dual boot system. Is it a good idea to install megaSync on both OSes? What filesystem shall I use (ntfs/exfat/ext4/etc.)? Thanks! (As a reference, I installed the client on both OSes for another file syncing service I'm using. It works mostly fine, except tending to generate more file conflicts than it should)

[mattw-mega]

Hi @cihe13375 , That should be fine on a dual boot system when they each sync different folders (ie, they are completely independent). We have had reports of strange behaviour with the production version when dual boot instances try to sync the exact same drive shared between those instances, and that seems to be due to the way the OS presents the file data, which can have different details as seen by MEGAsync. However if you try it, I would be very interested in any issues you see. Certainly avoid any variant of FAT, as that one does not have proper IDs for each local file, which MEGAsync depends on (the FAT driver will generate some, and MEGAsync will try to use them, but they are not reliable). ntfs and ext4 have proper file and folder IDs. And, I've copied Ubuntu 22.04 installers to the 5.0.15 folder link - let me know if those are not the right ones for you. thanks

[cihe13375]

Just tried the ubuntu version. After adding a folder which should be almost already synced (it is one of the synced folders I originally have on Windows), the transfer manager went like this (I retrospectively took the screenshot after transfers were completed): After some investigation I found that megaSync uploaded the whole Rubbish folder (that's about 100GB!) to the server. Luckily the client on my other Windows PC does not download that folder (yet), otherwise my hard disk would have been exploded. Anyway, is uploading the Rubbish folder the desired behavior? I didn't encounter this when I was on Windows. The local folder in question is on an NTFS drive, in case that matters. The Rubbish folder is correctly shown as hidden in Dolphin, but not when running ls in bash.

[sawft99]

After some troubleshooting I noticed upon updating that I had installed to my appdata rather than my program files where I previously had it. I think both may have been trying to run at the same time or something as I suddenly had a lot of corruption, broken links, etc. Maybe something in the update process to check and see if you already have it installed in either location so no one has similar issues?

[Kovur]

The "some issues occurred" needed a checkbox "In case of name conflict, consider local file as the most recent." Because it's impossible manually confirm so many files.

[sawft99]

The "some issues occurred" needed a checkbox "In case of name conflict, consider local file as the most recent." Because it's impossible manually confirm so many files.

I think might have mentioned this before but yea 100% either way.

[mattw-mega]

Hi @cihe13375 , I see you are trying that scenario: dual boot win/linux, and both syncing the same folder in the same shared filesystem (right?). So, historically, MEGAsync has used "Rubbish" on windows and ".debris" on linux/mac for the name of the folder into which files/folders that the sync removes/replaces go. The sync automatically ignores its own rubbish/debris folder (but only considers its own platform). That original decision didn't take your scenario into account, so on the other platform, it would see and process that folder like any other. Except that the linux folder .debris would be ignored on windows anyway, due to the ".*" default exclusion. On linux though, Rubbish is not automatically excluded. You can add that to your .megaignore file for that sync, and that should solve that problem, eg with:

-N: Rubbish

thanks

[mattw-mega]

Hi @sawft99 , MEGAsync has always installed its windows executables to AppData since before I started at MEGA, in 2017. However it's possible that much earlier installers might have installed to Program Files (and remembered that location when running the installer for updated versions), though that would likely mean that the auto-update couldn't work. If the installer (based off NSIS) did maintain that, we didn't change anything to cause it to fail for that case. Anyway, if so, apologies, but things should be smoother from AppData. thanks