copying hidden files
how do you copy hidden files from one directory to another?
|
if you mean the "hidden files" as the files that have dot in front of their filenames (like .xinitrc or .bash_profile), then their copying goes quite normally from the command line: (the first example means you're in the directory you copy the files from, and the second is with full paths)
Code:
cp ./.hiddenfile /path/to/another/place/ Code:
cp /path/to/file/.hiddenfile /another/path/ |
i know how to copy one hidden file. i mean to copy _all_ of them at the same time (there are loads).
|
cp .* otherplace
|
ah yes, if you are in the directory you want to copy from it works, but if you are in the directory you want to copy to, it doesnt, it start copying everything up from that as well.
|
try:
Code:
cp /the/dir/where/you/copy/from/.* ./ |
thats the one that doesnt seem to work, or is it if you use the -a option with it perhaps? it seems to copy up from that directory as well.
|
The problem is this:
when you use the full path with the .* wildcard, it matches two special entries: "." - the current directory ".." - the parent directory You can prevent that by changing your command to this: cp /the/dir/where/you/copy/from/.[^\.]* ./ What that says is, "Copy everything that starts with a dot and does not have a dot as the second character". Since the current directory is a single dot, this won't match it, and since the parent directory is two dots, this won't match it either. However, if you have any files such as "..some_file", they won't be copied over either (very unlikely). If you do, though, then I would suggest using the find command or a simple shell script rather than cp. |
thanks all.
|
Quote:
I use cp to copy rapidly all my home directory files as often as I want to to another hard drive. It has been working fine, except for all the screensful of error messages relating to the dot representing the current directory! Now I will have a neater, and a little bit faster, routine. I also use two other backup methods, which take a lot longer, to copy less often system files and home files, but for some reason they are neither one as foolproof as the plain cp command. They don't always capture all the files, while cp does. I'm reluctant to use tar with gzip because I've read that gzipped files are useless past the point of one single error in the archive. |
Actually, the command I gave works, but the backslash is not needed. In other words, this will work also:
Code:
cp /the/dir/where/you/copy/from/.[^.]* ./ Yes, it is possible for a gzip archive to become corrupt, but you can always test it. Tar has a verify option (-W, --verify) to check an archive file once it's created. If it fails, you can try again. If it checks out, then you're good to go. The media you store it on might get corrupted at some point, but you run that risk with anything: hard drive failure, floppy disk going bad, CDR getting scratched, etc. You don't have to use it if you're not comfortable with it. Just realize that lots of software projects provide their programs in a gzip'ed tar format. So, archive corruption can't be that big a problem. On a personal note, I've never come across a corrupt gzip archive. |
Quote:
Good to know about the verifying process with tar and gzip, and that gzip may not be a problem after all. Tar is certainly a handy and relatively simple way to make very quick copies. I'll probably head back in that direction now! Thanks again. |
you mean an "uphill struggle", if your going uphill you are by default climbing. </pendent> ;)
|
you could use bzip2 with tar. it's safer.
Data recovery bzip2 compresses blocks of data independent from each other. For each block, a checksum is created and stored. That's why all non-corrupted compressed data blocks can be easily detected and recovered. The tool bzip2recover which is available from the bzip2 homepage can do this. |
doesnt bzip2 compress better than gzip as well?
|
All times are GMT -5. The time now is 02:16 AM. |