New answers tagged rsync
It's largely academic, because your limiting factor will most likely be your network bandwidth. The only thing to watch for really, is sizes of files vs numbers of operations - lots of small files will result in lots of small copy operations. But as it stands - it's hard to say for sure what will be 'fastest' because 'it depends'. I would be surprised to ...
You can't get rsync to stop when it has copied a certain amount of bytes by providing a limit. You can run it normally rsync -a /src/ /dest and when /dest is full it will just stop with an error rsync: write failed on "...": No space left on device (28) You could do something with a script find /src -printf "%p %s\n" >filelist_size Then use ...
My understanding is that what you want is not possible, at least not with rsync.
I've been trying to figure out how to keep rsync from copying every file every time, for a long time, with no success. But I've just stumbled across the answer. It's a FAT32 short-filename issue; apparently, by default, Linux converts them to all lower case, which messes up rsync's ability to see that it's the same file on the source & destination. The ...
It ended up being a syntax issue. Using the -a (archive) switch fixed it. My initial syntax wasn't copying the "file modified date".
I can see three obvious possibilities right off the bat (and I am sure there are more that even I could think of if I spent some time considering this): Don't allow random users to run random commands, or commands that allow breaking out into an environment that will allow running random commands (such as an editor launching a subshell or saving files into ...
Top 50 recent answers are included