Live data from Hacker News

Transfer.sh – File sharing from the command line

transfer.sh

111–117 of 117 posts

Re: Transfer.sh – File sharing from the command line

#111
post #57

There are so many tools that can transfer files between two computers. I really like ones like this because you don't have to have SSH access or forward any ports to send a file from A to B. Its similar vein to other peer-to-peer utilities like zget [1], sharedrop [2], instant.io (webtorrent) [3], filepizza (webtorrent) [4], magic-wormhole [5], toss [6], dat [7], and many many others. During Hacktoberfest I also star…

Shameless plug: I wrote ffsend (https://github.com/nneonneo/ffsend) to interact with the Firefox Send experiment (send.firefox.com). With this, you can upload a file which is end-to-end encrypted (i.e. it is uploaded encrypted, and only you have the key), and accessed via a simple URL that you can share with your receiver.

FF Send files last for 24 hours, and you can configure the number of downloads allowed from 1 to 20. The maximum filesize is around 2 GiB. The reason I wrote ffsend is that the official site loads the entire file into memory in order to en/decrypt it, but my script is able to stream the en/decryption and thus significantly reduce memory usage.

Re: Transfer.sh – File sharing from the command line

#112
post #40

I like it! But for me ssh already provides a simple and secure way to move files from one place or another.. tar -cf - ./files.txt ./orDir/ | ssh host "(cd /dest/dir; tar -xf -)" Given that ssh it so ubiquitous I think this will always be my go to.

>Ha ha, I remember writing a command like that (made it into a script for repeated use, with args) when one of our HP-UX servers in the company where I worked then, had a DAT drive failure. The script allowed us to take backups of the source code and data on one such box from another box (connected on the same network), until the bad drive was replaced a few days later.

Didn't know about nc or rysnc at the time. Good to see those other solutions, and good that there are many ways to do it, with different pros and cons.

Re: Transfer.sh – File sharing from the command line

#113
post #96

Earlier quoted context omitted.

What about just typing rsync -havz --progress source destination? -h for human-readable numbers -a for archive mode -v and --progress for verbose info -z for compression during transfer Add a -n for a dry run if required. https://linux.die.net/man/1/rsync One of the people who came up with it - Andrew Tridgell - was more or less "responsible" for Linux and BitKeeper parting ways, which in turn ultimately lead to the…

Yo dawg, I heard you like progress, so check out rsync's --info=progress2 You can use it since rsync version 3.1.0.

Hah I've seen that in the man a few times but always feel too lazy to call it up. Next time I'll give it another go!

Re: Transfer.sh – File sharing from the command line

#114
post #86

Earlier quoted context omitted.

rsync has always been my favourite because it makes the most sense to me (and the --help/man page is easy to read). rsync -n -avh --progress source destination:~/asdf/ for a dry run followed by ctrl-p, ctrl-a, alt-f, alt-d, alt-d to remove the -n flag and then execute that for the real thing. Occasionally though, I'll also use sftp if I'm just pulling one thing - perhaps even after sshing to the remote machine. For a…

After all these years, I still can't keep straight when I need a trailing slash in rsync, and when I need to not have it.

If you think of it in terms of archives and whether you want to "extract" into the current directory, or a new directory within the current one; that might help.

rsync source destination will plonk the entire source directory and put it inside destination as a neat bundle.

rsync source/ destination will take the contents of source (but not the directory source itself) and plonk it in destination

I found the info page a little dry but it does describe it succintly:

    rsync -av /src/foo /dest
    rsync -av /src/foo/ /dest/foo
For some reason though, my head freaks out when it sees "foo" and "bar", but all they're saying is that it does the same thing.

If in doubt though, just chuck everything into the destination ~/temp/ or ~/asdf/ and sort it out later.

To be honest though, most of the time I just use fish shell's autosuggestions to guide me along.

Re: Transfer.sh – File sharing from the command line

#115
post #95

Earlier quoted context omitted.

tar cf - src/ | ssh $host "tar -C /dest/dir -xf -"

Do you have any idea about a crazy fast way to transfer files between two machines on the internal network? No encryption necessary No integrity checks No resume support Just plain and as fast it could get.. I need to try the netcat version but I'm hoping someone could show me a concurrent version of it that is mad fast.

From your source machine:

  
On your destination machine:

  ncat -l 8001 > /path/to/dest
Though in most situations with files of reasonable size, you're probably going to be better off running through `gzip -c`.

Re: Transfer.sh – File sharing from the command line

#116
post #44

Earlier quoted context omitted.

Unless you are storing hashes, what would prevent someone from writing a script that simply reuploads the file to your service after downloading? That would increase the share limit.

Let's say you generate the identifier for the upload based on the file hash. If you add a timestamp or random nonce then they'll have to redistribute the link to the file every time they re-upload as it will change every time.

Exactly. Nothing would stop someone from re-uploading it, but they'd end up with a different url which would go dead pretty quick if used to share something publicly.

Re: Transfer.sh – File sharing from the command line

#117
post #79
post #75

Earlier quoted context omitted.

I usually go straight to tar & ssh over scp since you can do directories where you can't with scp. But yeah, if you just have some files scp works.

You can obviously send directories with scp, just use -r. Or am I missing something?

Well I'll be damned.. not sure what lead me to think this.
Post reply on HN