Re: [Bug-tar] tar and file meta data....

[Joerg Schilling]

Tim Kientzle <address@hidden> wrote:

> > And Apple's file system also supports alternate data/resource forks.
>
> I'd be interested in an example showing a case where
> it's actually useful to transfer extended data between
> dissimilar systems.  Apart from ACLs (see below), I've
> yet to see any case where it was useful to do so.
>
> Are MacOS data forks ever useful on Windows?
> Windows streams on Linux?

What Apple does is an extremely simple support for alternate streams.
What MS does is still a subset of what is implemented on Solaris and what has 
been standardized with NFSv4. Given the fact, that Microsofts attempt to 
standardize their system in POSIX was rejected in August 2001 because it 
disallows ':' to be part of a file name and given the fact that 90% of the 
openat() features to support NFSv4 extended attributes has been standardized
with POSIX.1-2008 already, this seems to be the right way to go.

If I start implementing support, I will do for the superset from Solaris as 
this makes it easy to support the known subsets.

Sun unfortunately implemented support for extended attributes using very 
obscure and outdated POSIX.1-1988 extensions, so we need to discuss a better 
archive format.

> > star has (a multi tar format tar prog from the 90's has had
> > support for ACLS/extended attrs -- ?
>
> Last I checked, Joerg only supported POSIX.1e ACLs with star.

Well, when Sun came out with NFSv4 ACLs, Sun had major design bugs in the 
related support library. This is why I _could_ not support NFSv4 ACLs when they 
came out. Sun still added support to tar with that buggy lib using outdated 
POSIX.1-1988 extensions....

It took two years for Sun to fix the design bugs and then I tried to discuss 
the tar format for that feature based on the much better POSIX.1-2001 
extensions but Sun did not show any interest.

> > so...  plans for tar?
>
> As part of my ongoing work on bsdtar, I've worked up a design
> for storing NFS4 ACLs in tar archives:
>
> http://code.google.com/p/libarchive/wiki/TarNFS4ACLs
>
> I have some of this implemented.  I'd be very interested in
> feedback on the design.

Thank you for this research.

Please note that the short ls -V ACL output that I introduced, was designed to 
help humans to be able to make a quick scan of permissions. It does not look 
like something that is extendable for a non human parser without causing 
problems in case that somebody decides to add new features at a different 
location than the end of the string. 

For this reson, I did never plan to use this format inside tar even though it 
consumes less space in the tar header.

The currently planned format for NFSv4 ACLs is to use a modified ls -v output 
(that includes user/gid ids besides the names) as a POSIX.1-2001 extension.

If you like to discuss this, feel free to subscribe to:

        https://lists.berlios.de/mailman/listinfo/star-developers

and start a discussion.

> > When will it be usable for archiving again? -- I mean it's good for content 
> > transport,
> > but permissions -- not so good...since most of win's permissions are in the 
> > ACL's.
>
> Extending tar to work well with Windows would be a pretty complex undertaking.
> Windows has a very different set of file types, filename patterns, and 
> permissions
> than POSIX utilities such as 'tar'.

What "file types" do you have in mind?

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/private/ ftp://ftp.berlios.de/pub/schily