Tag Info

Hot answers tagged


To copy a file from B to A while logged into B: scp /path/to/file username@a:/path/to/destination To copy a file from B to A while logged into A: scp username@b:/path/to/file /path/to/destination


Master connection It's easiest if you plan in advance. Open a master connection the first time. For subsequent connections, route slave connections through the existing master connection. In your ~/.ssh/config, set up connection sharing to happen automatically: ControlMaster auto ControlPath ~/.ssh/control:%h:%p:%r If you start an ssh session to the ...


%CPU should be low during a copy. The CPU tells the disk controller "grab data from sectors X–Y into memory buffer at Z". Then it goes and does something else (or sleep, if there is nothing else). The hardware triggers an interrupt when the data is in memory. Then the CPU has to copy it a few times, and tells the network card "transmit packets at memory ...


The linefeed character (also known as newline or \n) is the one that when sent to a terminal tells the terminal to move its cursor down. Yet, when you run seq 3 in a terminal, that is where seq writes 1\n2\n3\n to something like /dev/pts/0, you don't see: 1 2 3 but 1 2 3 Why is that? Actually, when seq 3 (or ssh host seq 3 for that matter) writes ...


SSH does support a few commands, via the escape character (~ by default): $ ~? Supported escape sequences: ~. - terminate connection (and any multiplexed sessions) ~B - send a BREAK to the remote system ~C - open a command line ~R - Request rekey (SSH protocol 2 only) ~^Z - suspend ssh ~# - list forwarded connections ~& - background ...


There's but one way to determine the optimal block size, and that's a benchmark. I've just made a quick benchmark. The test machine is a PC running Debian GNU/Linux, with kernel 2.6.32 and coreutils 8.5. Both filesystems involved are ext3 on LVM volumes on a hard disk partition. The source file is 2GB (2040000kB to be precise). Caching and buffering are ...


Patrick has it more or less correct, but here's why. The way you copy a file under UNIX works like this: Try to read some (more) bytes from fileA. If we failed to get bytes because we're at (or past) the end of the file, we're done; quit. Otherwise, write the bytes to fileB and loop back to step 1. Knowing that, and knowing it's as simple as that, lets ...


If you have rsync (remove --dry-run to do it for real): rsync --dry-run --remove-source-files -avHAX /unencrypted/ /encrypted Otherwise, using bash4+ and GNU stat: #!/bin/bash set -e shopt -s nullglob globstar for from in /unencrypted/**/*; do to="${from/\/un//}" if [[ -d "$from" ]]; then echo mkdir -p "$to" echo chmod "$(stat ...


As Celada mentioned, there would be no point to using multiple threads of execution since a copy operation doesn't really use the cpu. As ryekayo mentioned, you can run multiple instances of cp so that you end up with multiple concurrent IO streams, but even this is typically counter-productive. If you are copying files from one location to another on the ...


It's easy using the install program from the coreutils that is typically used for this very purpose by build systems like automake: install -D /path/to/source /path/to/destination Note that install creates all parts of the path just like mkdir -p does, see man install. I'm curious why you didn't include why you want to do that. Calling mkdir and cp is ...


Those are all very complicated methods. You can mount the remote file system on your local machine with sshfs: mkdir -p /mnt/sshfs root@IS1300:~# sshfs /mnt/sshfs root@IS1300:~# umount /mnt/sshfs Then you can copy paste the file with nautilus, gnome, konqueror, dolphin, bash or whatever.


rsync --verbose --archive --dry-run /oldisk/a/ /newdisk/a/ The --dry-run (or -n) will do a dry run, showing you what it would do without actually doing anything. If it looks ok, run the rsync without the -n option. This will be a copy, not a move, which isn't quite what you're doing, but is safer. The --archive (or -a) ensures all the ownership and ...


How about something like this in bash: for file in ABC.*; do cp "$file" "${file/ABC/DEF}";done you can test it by putting echo in front of the cp command: for file in ABC.*; do echo cp "$file" "${file/ABC/DEF}";done


Are you using a 64-bit version of Linux with a lot of memory? In that case the problem could be that Linux can locks for minutes on big writes on slow devices like for example SD cards or USB sticks. It's a known bug that should be fixed in newer kernels. See http://lwn.net/Articles/572911/ Workaround: as root issue: echo $((16*1024*1024)) > ...


I think you should do something like the GUI applications do. My idea for doing this is to write two functions for Copy and Paste, where Copy writes path of files to be copied to a temporary file and Paste reads those paths and simply calls cp command. My implementation (to be put in .bashrc file) is like below: function Copy { touch ~/.clipfiles ...


Try to use such next function for such situation: copy_wdir() { mkdir -p -- "$(dirname -- "$2")" && cp -- "$1" "$2" ; } and use it as copy_wdir aaa/deep/sea/blob.psd bbb/deep/sea/blob.psd By the way, GNU cp has a --parents option. It's really close to what you want, but not exactly. It will also create aaa directory that seems you don't need. ...


dd dates from back when it was needed to translate old IBM mainframe tapes, and the block size had to match the one used to write the tape or data blocks would be skipped or truncated. (9-track tapes were finicky. Be glad they're long dead.) These days, the block size should be a multiple of the device sector size (usually 4KB, but on very recent disks ...


This could, possibly, be a faster alternative, and you won't clog the network for two days: Take one or two large USB (USB 3 if you have it) or FireWire disks, connect it to the server and copy the files to the disk. Carry the disk to your local machine. Copy the files to the machine.


rsync is able to do this. rsync --ignore-existing <src> <dest> You can perform also various kinds of updates. Just have a look at the man page.


mkdir ~/dst find source -name "*.xxx" -exec mv -i {} -t ~/dst \;


Using rsync can accomplish this. Based on the type of system you have, you will need to donwload it: sudo yum install rsync (RPM Based) sudo apt-get install rsync (Debian Based) Then using this, here is the command you will need to use: rsync -a source destination Or rsync -r source destination Where -r stands for copying data recursively (but don’t ...


The magic of rsync filter rules: $ rsync -av --filter="+ */" --filter="-! *blah*" /source /dest Consult the rsync man page for the details on filter rules, but here's the condensed version for this particular need. --filter="+ */" means "include everything that is a directory" --filter="-! *blah* means "exclude everything that does NOT include blah in ...


The quick way The quickest way to transfer files over a LAN is likely not rsync, unless there are few changes. rsync spends a fair bit of time doing checksums, calculating differences, etc. If you know that you're going to be transferring most of the data anyway, just do something like this: user@dest:/target$ nc -q 1 -l -p 1234 | tar xv ...


Your definition of efficient is backwards. A more efficient implementation wastes less cpu time. On the local copy you are averaging about 74 MB/s of throughput ( read + write ), which is about as good as a single hard disk is going to get.


Install sshfs: sudo apt-get install sshfs create a empty dir mkdir /home/user/testdir "link" or "mount" the two directories sshfs user@server.com:/remote/dir /home/user/test "unlink" the dirs fusermount -u /home/youruser/remotecomp For more see here, linuxjournal.com


Well, I believe you could use gnu parallel to accomplish your task. seq 70 | parallel -j70 cp filename You could see a detailed explanation on using gnu parallel from my other answer here. I just tested the above command in my system and I could see that 70 copies of files are being made.


If fileA.big is grown during the copy, the copy will include the data that was appended. If the file is truncated shorter than where the copy is currently at, the copy will abort right where its at and the destination file will contain what was copied up to the time it aborted.

Only top voted, non community-wiki answers of a minimum length are eligible