> Well, I left out two things, anyway. I always do the full nine yards of
> scp -- with -r, and both IPs, full paths, the works -- just because
> that's the only I have a better than even chance of getting it right and
> making it do what I mean it to. Also, for the record, I usually did all
> of /home, as root (in order to get things like root's .bash_history); so
> of course I also had to do a chown at the other end.
You put root's home directory in /home? Just FYI, that's not a safe
thing to do. It means if you're trying to recover a system and
/home isn't available you have no configuration files for root, and
additionally, any files created by root in the home directory will land
in /. There's nothing like being in a tough spot and trying to recover
a system and having none of your carefully configured system behave as
expected. This is what will happen if you have root's home directory in
/home.
The way the file-system should be structured is that you can perform all
recovery operations with *only* the / partition mounted.
Back in the day the root user didn't have a home directory. It was
called "root", in part, because the home directory was in the root of
the file-system. People decided this was a bad idea years and years ago,
though.
I highly recommend you spend some time playing around with some of
the command-line options. It is a bad habit to over-complicate your
command-lines. You can inadvertently find yourself having problems
that other people just don't understand, as they're side-effects of
command-line option interaction.
Additionally, when you use a lot of command-line options, you're opening
yourself up to more bugs and hard to reproduce behavior. While a lot
of the programs you use are probably reliable and well-tested, in many
environments the rare/obscure combinations command-line arguments are
the exact places where the rare/obscure bugs lie. Option A may work well
and be well-tested. Option B may work well and be well-tested. Option
A+Option B may interact in ways that are non-obvious, flat-out buggy,
and potentially unreproducible.
> But the relevant point to what I was answering is only that tar does not
> follow symlinks by default; if you want it to track them down and include
> them, you have to tell it to. Otherwise, using it for the purpose I did,
> you gradually accumulate obscure but irritating failures of exactly the
> kind of things I was trying to preserve.
I had to scratch my head on this one.
Why would you want tar to follow symlinks when copying home directories?
Tar normally stores and restores symlinks as symlinks. If you're
symlinking to things which change locations across machines in your
network, then it is expected that things fall apart.
For instance, at home with my personal user account, I keep all my data
stored one level deep with a dash of source control, and a makefile here
or there to establish symlinks. It allows me to easily backup the data
I want to keep and ignore the crap that doesn't interest me. All of the
symlinks I use in my home directory relate directly to other directories
in my home directory. (And they should all be relative links, so they
can be moved safely. This also allows me to have multiple copies of that
data tree and retain internal consistency.)
This also means that if symlinks were followed, I would get massive
data duplication, some of the source control would be violated, and
I'd no longer be able to as easily create backups of the stuff that is
important to me. As an example of some of the massive data duplication:
Some things have created both a 'Music' and a 'music' folder in my
home directory in the past, both of these, for me, are symlinks to
Media/Music, but Media itself is a symlink in to the directory I backup
regularly. If you follow those symlinks, then all my music would be
duplicated 3 more times.
Cheers,
Steven Black
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug
