megatools
megatools copied to clipboard
megous
Release 1.11.0
Some ideas I had and/or gathered from others for improvements. These are the big/complicated ones:
- [x] Make megatool easy to build statically into a single binary executable with no external dependencies that can be used on any Linux distro without hassle. That's done.
- [ ] Improve progress output of the tools. (display estimated time of completion, average the speedometer's value over the last 5-10 seconds, so that it's less jumpy than the current 1s interval) Perhaps display total for all the queued transfers, not just the current one.
- [ ] Optimize transfers of multitudes of small files/minimize TCP roundtrips.
- [ ] Some kind of a rsync like funcionality.
Smaller stuff:
- [x] Public key pinning (so that megatools doesn't depend on certificate authorities for authenticating mega's api servers)
Feel free to chime in with your pet peeves/stuff you'd like to see. If it's small enough it might even fit into the next release. ;)
Here are experimental portable binaries: https://megatools.megous.com/builds/experimental/
so no more megacopy but megatools copy
will test the experimental binary and see what I need to modify in the completion script.
You can use --enable-compat-symlinks to install symlinks to megatools binary and get the old behavior/interface. Static binaries are big, so it's better to have a single 4MB binary rather than 8x 4MB binaries. But yes, if you want options completion with the new megatools binary itself, you'll need to modify the script.
Please put the commas back in the transfer file size, I'm not fuckin rain man I can't decipher all that shit.
@AssRap3r I get this:
./megatools get --limit-speed 1000 /Root/testdir/c2c77c034d771b76a5c739291273d1b612ba142d
c77c034d771b76a5c739291273d1b612ba142d: 28.29% - 2.0 MiB (2,128,840 bytes) of 7.2 MiB (1000.1 KiB/s)
Not sure what you're talking about.
@AssRap3r Static binaries have nls disabled and always run in POSIX locale with the default language of the application. I guess something to live with if you want to use them. They're meant to be mostly independent from the host system, to have something you can drop on a remote system that is too old or slow or unable to compile the megatools the regular way. Otherwise just use the regular installation method that has full support for locale specific formating of numbers.
Also if you can read the units, you should be fine with just the number before the parenthesis. I might just as well remove the (2,128,840 bytes) to reduce the noise.
Would you care to elaborate how did you build the static binary? I see compiler x86_64-pc-linux-musl among others..
feature request:
let megadl recreate the directory tree locally of a folder link (starting from folder name).
Something like:
megatools dl --path ~/local/dir --dirtree $megalink
WARNING: chunk upload failed (Chunk upload failed: CURL error: Failed sending data to the peer), aborting transfer XXXX.rar: 100,00% - done 1000,0 MiB (avg. 48,3 MiB/s) ERROR: Upload failed for 'D:\XXXX.rar': Data upload failed: Upload transfer failed: Chunk upload failed: CURL error: Failed sending data to the peer
How can I disable the .megatmp files and just have it download to the file as it did in the classic mode using megatools dl?
Personal preference, and it seems to overwrite downloaded files if I run the command twice (for example to download the same folder on two separate threads).
Oh sorry, I was copying the path with the folder path on the end one one of the windows I was testing with, that used to not work! One more issue but this might not be megatools, it might be the command prompt, but is there a way to get it to overwrite the previous line with the % downloaded instead of spamming it constantly on a new line?
It does overwrite the last line. There are some exceptions. If the line wraps to multiple lines, it will overwrite just the last line, which may lead to spamming. If the output is via a non-tty device, it will not try to use any special handling and will separate progress updates with LF, instead of CR.
Is there any way an ETA could be provided when uploading/downloading files with megatools?
Make megatool easy to build statically into a single binary executable with no external dependencies that can be used on any Linux distro without hassle. That's done.
An out of box docker image could be another (easy) way to get both simplicity and cross platform support.
An out of box docker image could be another (easy) way to get both simplicity and cross platform support.
How so? Static binary can already be used almost anywhere without any supporting software. Just copy one file and that's all that's necessary to run megatools.
@megous Well, I'm not saying static binary is not a good solution. But comparing its cost on development and maintenance, docker image is a far more easy way (less than 1 hour) to achieve an out of box experience and better cross platform at the same time. I would rather see it as another option rather than a replacement of the static binary version.
Yes, but you're just emphasizing what you already said. Megatools is already cross-platform and out of the box, just like any other GNU/Linux package based on autotools. In fact it can be built with generic ./configure && make && make install on GNU/Linux, Android, BSDs, Windows, multiple CPU architectures, etc. Meanwhile Docker is not cross platform at all. It's just Linux.
To me, there are two issues to be solved:
- easy build on wide array of systems - solved by autotools
- easy install on old systems/systems where users are not used to building their own software (like Windows) or it would be a lot of work - solved by static binaries
I just don't see any benefit/improvement for users compared to what's already available. Static binary can be installed in 1-2 minutes, and is ~50x smaller than a random base Linux distro you'd be pulling in with Docker, thus much simpler and less confusing for users. I mean why would someone want to pull in an entire Linux distro, have to manage that distro, keep it updated, etc - just to use megatools?
Also Docker is just one of many container solutions, and not even as widely supported as others (like systemd-nspawn). So even if providing a container would be helpful, Docker would probably not be my first choice.
But feel free to provide a docker script or however it's called, I'll gladly add it to the contrib/ directory, if you find Docker useful. It will just not be supported/maintained by me. But perhaps others who are used to Docker may find it useful.
If you agree on what I have said before. Then I can't see why it should not be an alternative option.
'easy' build by autotools? I failed twice on a brand new Debian stretch-slim enviroment. Google several times to fix some wired enviroment and version dependency problems. Yes, it must be my personal problem of lacking certain knowledge and experience. But if 'easy' is meant to used by as many people as possible and you really care a bout it. Why not give extra solutions that can make it easier?
Also for most container users, common base linux distros layer have already been used and cached by so many images. Pulling a well built image is not that different from apt/yum/brew. Even better if considering different versions of library and those annoying depency problems.
As in my case. I used megatools on a 7*24 NAS system. Which has over 30 TB of storage and runs many different storage type tasks. Like, download/upload/sync files with different cloud storages, personal email/git/video/audio server, time capsule server and etc. Stability is way more important than some reasonable extra space consumption. Using containers to keep all these enviroment isolated is one easy way for me.
The real lesson I learned is to read the doc to bottom before take an action. Only if I know there is a pre-packaged binary out there. I will definately not try to build it from stretch.
Thanks for a good project.
That's my point from the beginning: I don't agree with what you said. :) It already can't be easier:
apt install megatools (inside docker)
And you're done.
If you feel megatools in stretch is outdated/broken, ask your distribution of choice to have it updated (there's a case for it, because of mega.nz's subtle API changes), or use sid.
@megous, could you please add build/ to .gitignore in your repo (https://megous.com/git/megatools)? When building from source, Git would consider the files in the meson build folder as untracked. Thanks. :smiley: Keep up the good work! :+1:
