Quoting Bruce Ferrell (bferrell@???):

> Sorry Rick... I missed that.

No worries (as our Australian friends say).

> I am absolutely astounded by the number of time I've seen *IX
> "admins" at fortune X companies copy a tree to a windows share and
> wonder why it's broken when they try to restore from it. NFS, if not
> done correctly, can do that same thing too. So...

Reminds me of something I forgot to mention earlier. Most Linux folks
have heard of the stat(2) system call, but did you know there's also an
informative stat(1) system _utility_? Play with it on diverse sorts of
file/directory targets, and see how informative it is. It shows in
human-readable form _all_ metadata available about any filesystem object.

Around 2001 when I was writing an article for _Linux Journal_ about
then-new USB flash drives called 'Floppies for the New Millennium', it
belatedly occurred to me to wonder how the vfat filesystem (typically
used on flash drives) dealt with storage of native *ix's three time
stamps (ctime, mtime, atime) on a filesystem (vfat) incapable of storing
more than a single time stamp. The answer is logical: All three get
instantiated by overloading the single DOS time stamp, which thus gets
rewritten every time any of them must be updated. And, point is, one
can observe this kludge at work using /usr/bin/stat.

Anyway, to second what you said: Any storage target that's not
Linux-native, and NTFS is case in point, is going to unavoidably
introduce some degree of silent metadata loss (absent encapsulation,
such as in a tarball), so beware.