> > '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, <[email protected]> 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.
Yes, I got warnings, I was pulling all of the files off of five failing hard drives. Luckily, the files were just some pr0n videos, but it could have been really bad if the hard drive was on it's very last run. > > > > 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. > No, I didn't know. I have had lots of problems when ownership changes with the symlinks, so I wrote I program to delete and restore them with the proper owners. Thanks for letting me know. I can delete the files I had left on the old partition. > > > > 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. > Thanks, Chris Bennett
