Re: [Bug-tar] Support SCHILY.* options, please.

[Joerg Schilling]

Tim Kientzle <address@hidden> 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:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily