[ACL-Devel] archiving acls: tar and cpio

[Andreas Gruenbacher]

On Sat, 14 Oct 2000, Michael Ju. Tokarev wrote:

> Andreas Gruenbacher wrote:
> 
> BTW, Andreas -- did you noticied that I cross-posted my mail to both
> acl-devel and posix1e lists? (and your answer was sent to both lists
> also ;) ).

No, I was in a bit of a hurry before. No damage done, I guess  :-)

> Yes, we're not allowed to use this `security.*'. I'm still not
> comfortable to write to austin group maillist -- maybe we should
> consult/inform them also?

The Austin group is not intended to define and specify new features. Their
stated goal is to create a joint base document for POSIX and the Single
Unix Specification.

I haven't yet found out who wrote the pax specifications, and who revised
them between draft 3 and draft 4. There were a few changes beyond the
official scope of the Austin group, so I suspect another group is working
on them, too. I may be wrong in this.

Somebody on the Austin group mailing list should know...

> > The comma separated format would be non-standard, while the line separated
> > format would be valid input to setfacl. Setfacl (or rather the library
> > functions used) could also be modified to understand the id's directly.
> > Both formats could be easily supported, but only the line oriented format
> > is backwards compatible to 1003.1e draft 17.
> 
> Ugh.  1003.1e draft 17 refers only to format used by [gs]etfacl
> utilities.  That utilities are mostly for humans, not for archivers,
> but I agree that this format can be used inside an archive.

I'd suppose it's easier to reuse an existing format unless a significantly
superior format is necessary for some reason. The format used should most
probably be textual, so except for the uid/gid problem I see no problem
with the 1003.1e draft 17 formats.

Actually, both the comma separated and the line separated format is
defined by 1003.1e DS17. The only problem is the comma separated format
has no comments, so it's not possible to suff in additional information.

>   How about this two (separator does not matter):
>   user:oracle:23:rwx,group:dba:50:r-x,...
>   user:oracle#23:rwx,group:dba#50:r-x,...
>   user:#23:rwx,...  -- this one if there is no username for uid 23

I would not use ':' as that already is the field separator. Also, '#' is
not a good choice in comma separated format because it is used to
introduce comments in line oriented format. A parser that parses either of
the formats will likely break. Another printable character that is illegal
in user names should be fine, but I can't think of any right now.

Apart from being different from what Solaris uses, what's wrong with a
line oriented format with the id's in comments?

> Interesting that solaris can use both numeric or symbolic "names"
> (that can leads to conflicts -- what if we have real "user"
> named "1000" -- sometime ago we had have this).  If there
> is no name corresonded to some id used in fs, solaris
> will use that id (in dec) instead of name.

User names starting with a digit are rejected on my current (Linux)
system. Any commas ad colons are rejected, too.

> > Michael, what about implementing a very small subset of the pax extended
> > header format (no global extended headers, for example)? Compatibility
> > with Solaris concerning this doesn't seem worth much, as I would guess all
> > vendors (SGI, HP, Compaq) have their own incompatible format already.
> > Using the pax format would give us a decent chance of being compatible
> > with what will be in use in one year or two.
> 
> What does you mean here -- What is "implementing"? -- there are already
> two pax implementations available (among others) -- them are GNU
> paxutils and also some variant probably from *BSD [...]
> 
> Both already have full support for extended headers -- the only
> thing missed here is a support for this particular keyword(s)
> in extended header.

Alright, so that is not the problem. I didn't know that any of the free
pax implementations is beyond alpha state already.

In that case, I would rather try to improve pax rather than spend time on
extending old GNU tar. GNU tar is high on my personal ranking of most
awful standard packages.


Thanks,
Andrea.s

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message