Tim Kientzle <[EMAIL PROTECTED]> wrote: > Joerg Schilling's "star" archiver was one of the > very first to implement the POSIX.1-2001 extended > pax format, and some of his innovations would > be nice to see in GNU tar as well:
The archive format description is at: http://cdrecord.berlios.de/old/private/man/star.4.html > * SCHILY.dev, SCHILY.ino - Store the device/inode number for files, > similar to how cpio works. These meta data tags are used in "dump" mode of star to allow a ufsdump/ufsrestore like incremental dump/restore implementation. They only make sense together with SCHILY.dino and SCHILY.dir and allow to detect renamed files in incremental restore mode. Stars incremental mode is very efficient and only needs to write the time stamp for the last dump into a file /etc/tardumps like ufsdump does with /etc/dumpdates. All other information is inside the archive. If you create an incremental for a filesystem where a single top level directory has been renamed, gnu tar needs to archive the whole filesystem but star only creates a 20 kB archive. > * SCHILY.fflags - store file flags on systems (including BSD and > Linux) that support it > * SCHILY.acl - Store POSIX.1e ACLs. These are not POSIX ACLs but POSIX draft ACLs. Note that the POSIX ACL draft has been withdrawn in the last millenium. The currently only ACL interface that is covered by a standard is the NFSv4 ACL type that is bitwise identical to the NTFS ACLs and that is the native ACL type in ZFS. Star will soon support ZFS acls with SCHILY.acl as it is simple to distinct between both ACL text formats. > I would like to see the various open-source > 'tar' implementations cooperate on furthering the > standard. Sharing the best ideas from the different Well, I did try to encourage other developers (in special the GNU tar developers) to discuss archive format extensions _before_ they are implemented to no avail until now.... I am still interested in discussing tar archive format extensions before implementing them. > projects--GNU tar's excellent sparse file support; star's > ACL, fflags, and dev/ino approach; libarchive's handling > of POSIX.1e extended attributes--makes life better > for everyone. Did you recently check star? Star also has a lot of advantages with sparse file support: - star is able to correctly restore sparse files that _end_ in a hole, gnu tar is not (although it archives them). - star is able to archive sparse files in a 100% correct way. This has been implemented via an lseek(2) extension that I did develop together with the ZFS team from Sun. - if pathconf(name, _PC_MIN_HOLE_SIZE) is > 0, the file is sparse - lseek(f, val, SEEK_HOLE) seeks to the next hole - lseek(f, val, SEEK_DATA) seeks to the next data This interface has been implemented for ZFS and UFS and it has been send to the OpenGroup for the POSIX standard. Star is now alway much faster than ufsdump(1) - even for sparse files. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
