Re: CVS commit: src/external/bsd/libarchive/dist/libarchive

>> - the input data that we have no control over.

> The question is: how should the tool behave in this situation and
> what consequences does it have?

>  - extract filenames as octects verbatim, leading to unrepresantable
>    filenames that "ls" will not properly show and that are hard to
>    rename with the shell.

In what sense would they be unrepresentable?  Perhaps I'm just lacking
in imagination, but I don't see any such sense.

As for ls properly showing them, well, that is ill-defined; it depends
on what the use case in question (the human, script, or whatever that
consumes the output) considers "proper".

As for being hard to rename with the shell, if that's true you need a
saner shell.  Filenames have always been at risk of containing
arbitrary octet sequences, except for the semantics attached to / and
\0, and a shell that can't deal with them needs fixing or replacing.

>  - fail to extract (like after the change and like all other tools I
>    know in the same situation),

All other?  Meet my tar implementation, which treats pathnames as octet
sequences, uninterpreted except for the semantics attached to / and \0.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B