View Single Post
Old 04 August 2017, 01:38   #663
SCO_1
 
Posts: n/a
The way i update on linux is installing realpath, megasync and megatools, copy the 'new' folder i want to update to my mega cloud drive and use this script. The script removes all the local files whose names don't match in the cloud folder (meaning this is of use for downloaders, not the uploader that *wants* to delete and upload files from the local dir to mirror on the cloud). Then i use megasync to update the 'wrong checksum' and new files. Watch out for the megasync bug mentioned though.

As explained in the link, mega is rather terrible to keep public links downloads synced, but it's possible, in spite of the annoying bugs and missing features in megasync. Maybe megatools will fill the hole eventually. Unfortunately, mega is still the best upload service for syncing in spite of this. The main issue is megasync not working on public folders, which is just stupid imo; but this problem of outdated local files being uploaded to your 'copy' is annoying enough to merit a script too.

Anyway, i think i might end using the other script mentioned here, seems like it might be a better solution, because of less steps (taking advantage that every different whdload archive on the mega folder has a different name, instead of a general solution that has to care about checking checksums). This will fail if a upload of a different file with the same name happens, as i'm sure everyone is aware.

It's possible megatools will end up providing a 'safe' (with checksum check) public sync eventually, or at least a more safe download method with megadl that deletes extra files and files which look outdated (comparing file timestamps/creation dates). Megadl already works on public folders, and it already doesn't redownload files which already exist, it just needs to delete extra files to be nearly equivalent to a sync.

BTW, the RageV1 and RageV2 files mentioned 2 pages back appear to not get scanned correctly by fs-uae-launcher so they never appear on the autoconfig. It's probably to be expected from some illegal character or incompatibility from whatever library fs-uae-launcher is using borking on the archives. I don't know if turning them to lzx would help because these errors tend to be on the host side.
edit: nope. The reason for this appears to be the openretro db not having the correct entry yet. Shutting up now.

Last edited by SCO_1; 07 August 2017 at 03:53.
 
 
Page generated in 0.03842 seconds with 11 queries