New answers tagged


We can do it in two steps to ignore tiny_mce directory. Assuming all the directories start by lower case letters. scp -r USER@HOSTNAME:~/FOLDER/[a-s]* . scp -r USER@HOSTNAME:~/FOLDER/[u-z]* . Also, change USER, HOSTNAME, and FOLDER to the real values.


I know @polemon has already answered this. But doing my tad bit for quick solution. I had to do man rsync to know which switch I wanna use... rsync -avz -e ssh /file or sym link/to/copy/ user@ip:/dest/path/ Although, in your case you need to make sure that links are not broken!


If you want to move files on the same host system, which I guess you are doing with your mv, rsync could be a faster option: rsync -av --inplace -W /source/??????????_a1ac*.jpg /home/ubuntu/ntest/ --inplaceand -W are set to speed up the process. Should this yield another argument list too long error then you could feed lists to rsync Make the list with ...


Not as "good" as the find solutions, but another valid solution is to make the mv commands more granular. This does 4096 moves, with a fewer number of files moved per mv operation. FILEPAT=a1ac for i in $(seq $((0x000)) $((0xfff))); do H=$(printf '%x\n' $i) mv 1559704165_${FILEPAT}${H}*.jpg /home/ubuntu/ntest done


Your command, find . -maxdepth 1 -type f | ??????????_a1ac*.jpg |xargs mv -t "/home/ubuntu/ntest" Pipes the list of all the files TO all the files! find . -maxdepth 1 -type f -name `*_a1ac*.jpg` -print0 |\ xargs -0 -r mv -t "/home/ubuntu/ntest" will do the trick.


You're very close. You should use the -name option to find. And remember to quote the pattern. So find . -maxdepth 1 -type f -name '??????????_a1ac*.jpg' |xargs mv -t "/home/ubuntu/ntest"


You should use: find . -maxdepth 1 -type f -name '??????????_a1ac*.jpg' \ -exec mv -t destination "{}" + So maxdepth 1 means that you want to search in current directory no subdirectories. type f means find only files. name '??????????_a1ac*.jpg' is a pattern that matches with file you are searching. mv -t destination "{}" + means move matched files to ...


You are trying to accomplish two things: Copy the directory tree to the remote site Compress the data being transferred Other answers have mentioned using rsync, which can accomplish both goals (giving a "-z" option to rsync enables compression). tar is a good tool to accomplish goal #1, and with command line options (like the "z" flag given in other ...


If you have rsync then use that instead, as it makes use of existing files to allow it to transfer only differences (that is, parts of files that are different): rsync -az ~/Documents/projects/myproject/dist/ root@ Add the --delete flag to to completely overwrite the target directory tree each time. If you want to see what's going ...


Instead of creating a file on disk, you need to send the output of tar to STDOUT, so it can then be sent over the wire using ssh: $ tar -zcf - /path/to/files | ssh user@host "tar -zx - -C /path/to/destination" Note the "-" characters where you are using file names. These tell tar on the sending side to write to STDOUT, and on the receiving side to read ...


You are telling tar to write the tarball into the file dist.tar. With this command you are not sending the tarball to the remote machine. You must make tar write its output to stdout using -f -. The hyphen means stdout. If you add a -z option, then tar will compress the tarball before writing it to stdout, which is a good idea in 99% of all use-cases where ...


Actually you can, but kind of hacky.. and only as suffix. As you have read in the comments, --suffix is for backups of overwritten files. So you rsync the same files from source to destination, kind of forcing rsync to overwrite (-I) - but only if the source file is (-u) newer (which it never is) and using the -b, --backup option and define a backup ...


If you get one of the following error messages while mounting an NTFS partition (the first is my Win10 partition, the second is my data partition) root@debian:~# mount /dev/sda2 /mnt/winc Windows is hibernated, refused to mount. The disk contains an unclean file system (0, 0). Metadata kept in Windows cache, refused to mount. Falling back to read-only mount ...


It hard to say extactly what the problem might be, but there are some ideas you can try: Since the D state is uninterruptible sleep, which is caused most likely by I/O operations, I guess that rsync is waiting for I/O on a file which is not accessible for some reason. EFS and EBS are both remote filesystems. I had a similar issue with an NFS share. To ...

Top 50 recent answers are included