On Sun, 10 Dec 2017, vincent delft wrote:
> Did you tried pax ?
> some thing like: pax -rw -pe <source> <destination>
>
> I don't know if this the best tool, but I'm using it to duplicate a 1TB
> drive (having lot of hard links) onto an other one.
> I've done it couple of time, and I've do not see issues.
'pax' and 'tar' are actually the same binary so they have the same
limitation from the file formats that are supported, as well as any purely
internal limitations. "pax -rw" actually has file format limitations by
design, so it doesn't automagically free you from those limitations.
> On Sun, Dec 10, 2017 at 7:03 PM, <webmas...@bennettconstruction.us> wrote:
...
> > OK. I've tried to use both methods and just don't
> > get true duplication.
> >
> > tar
> > It can't work with file and directory names
> > that are OK in filesystem, but too long for itself.
> > Quite a while back I lost a lot of unimportant files
> > and directories that had absolute paths too long.
> > Why is this happening with tar? Can this be fixed?
> > If not, I'd like to add a note about that to the FAQ.
tar/pax should have emitted warnings about such files when generating the
archive; if that didn't happen it's a bug and we should fix it.
Depending on the exact failure you hit there may be ways to fix what you
hit.
> > dump
> > I had to move /usr/local to a bigger partition. growfs,
> > etc. I kept the /usr/local untouched and then dumped it
> > to the new partition, expecting a true duplication.
> > Nope.
> > It changed all of the program symlinks permissions.
You do know that the mode of a symlink has *no* effect on how the kernel
processes it, don't you? As far as the kernel is concerned, you can do
the exact same operations on a mode 0 symlink as on a mode 777 symlink.
> > Why is dump doing this? Can this be fixed?
restore did that because (a) it didn't matter, and (b) there was no API to
modify the mode of a symlink (because it didn't matter).
An API that can chmod a symlink _was_ eventually added: fchmodat(2). The
diff below makes restore preserve symlink mode.
Philip Guenther
Index: tape.c
===================================================================
RCS file: /data/src/openbsd/src/sbin/restore/tape.c,v
retrieving revision 1.49
diff -u -p -r1.49 tape.c
--- tape.c 21 Jan 2017 08:31:44 -0000 1.49
+++ tape.c 10 Dec 2017 21:33:10 -0000
@@ -564,6 +564,8 @@ extractfile(char *name)
if (linkit(lnkbuf, name, SYMLINK) == FAIL)
return (FAIL);
(void)lchown(name, uid, gid);
+ (void)fchmodat(AT_FDCWD, name, mode,
+ AT_SYMLINK_NOFOLLOW);
return (GOOD);
}
