Reaction score: 120
tar -czpfto create a .tgz file, and extract it on the other system with
tar -xzpf. I don't use this method for files owned by, for example, root or postgres, not only because of non-native system concerns, but also out of concerns that the user and group ownerships probably wouldn't be right, because the uid's and group id's probably wouldn't match, but I would expect any text files' or audio/video files' contents to be correctly transfered. The
-poption is to preserve file permissions, user and group ownerships, and timestamps. If you try to put the tar file on an msdosfs file system it can't be bigger than 4 GB, due, if I'm not mistaken, to the limitations of the msdosfs or FAT32 file system requirements.
You're looking at it from the wrong angle. It's not the filesystem that saves things in a tarball. It's the tar(1) application that collects the data and it simply doesn't collect any filesytem specific data.I don't know if there might be something embedded with ext3/4 which could be saved in the tar archive
The only things that might cause problems can be fixed withI'm just being cautious in asking for other users experiences. I don't know if there might be something embedded with ext3/4 which could be saved in the tar archive and might not be extractable to ufs...
--no-aclsarguments which will turn off the extended attributes. Most of the extended attributes will work on ufs or zfs file systems unless your tar file happens to have some experimental feature in which case it should be ignored. Modern tar files are in a POSIX format called pax and can be processed with the pax(1) command. Most Linux systems use gun tar gtar(1) and bsdtar(1) was an rewrite of that. There are a number of other tar programs around and some of them will make funny tar files in some edge cases but they can be tested before extracting them with tar(1), gtar(1), pax(1) or sometimes cpio(1) and rarely ar(1) for ancient suff.