Re: uzip extfs sanity patch

[Pavel Roskin <proski gnu org>]

Hello!

> > IIRC ST displays the Dec 31 2028. Actuall there is the date stamp like
> > 0xffff ( => year = 0x7f+1980, mon = 0xf, day = 0x1f ) and this is
> > exactly what is happening here. The only value that can be wrong here
> > (at least for unzip executables - studying its sources) is the month
> > number so the sanity range shrinkage is IMO ok here. And maybe there
> > should be the same (range) checks also for the year, date and other
> > data?
> 
> Extfs should be fixed to use some sane format,
> not ls -l... Fish has one quite reasonable...

This is quite irrelevant here.  If the format of the archive allows 15th
month (which would be impossible if time_t was used) and the archiver is
stupid enough to output the date as is, no amount of armoring the date can
make it valid.

In many cases, extfs scripts merely run commands that emulate "ls -l".  
To encode the date into an unambiguous format, the script should be able to
interpret the date, and I think that the C code can do it better than some
sed or awk script.

There are some rare cases when the program called by the script can output
date in a machine-readable format.  For example, "rpm -q --dump package"
will print the timestamps in the time_t format.  mailfs parses dates using
Perl, so it can print them in a machine-readable format as well.

However, this problem is with a buggy (or too pedantic?) program that
cannot output the date properly even in the human readable form, let alone
machine readable representation.

Speaking of fish, I don't think the date armoring has any useful function.
If you know the exact number of the space separated fields in the date
(and you do, since the number of arguments to "read" is fixed), then it
should be possible to tell vfs_parse_ls_lga() to process not more than
that number of fields.

Maybe vfs_parse_ls_lga() simply needs a flag to disable parsing year and
seconds in the same timestamp.

-- 
Regards,
Pavel Roskin