Incorrect zoo archive listing

[IceMan]

MC incorrectly lists zoo archive entries when entering it.

Test zoo archive have been attached.

mc -V output:
GNU Midnight Commander 4.8.17
Built with GLib 2.42.1
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish
Data types: char: 8; int: 32; long: 32; void *: 32; size_t: 32; off_t: 64;

[IceMan]

Test zoo archive

[IceMan]

Screenshot of issue

[IceMan]

Patch for uzoo extfs helper

[IceMan]

See attached patch.

I think you need to review extfs helper docs. In current MC uzoo helper uses "Mon DD YYYY hh:mm" format for DATETIME field (src/vfs/extfs/helpers/README) and such format leads to malformed output in MC.

But if I change uzoo helper DATETIME format to "MM-DD-YYYY hh:mm" then everything is working fine.

[zaytsev]

It seems that you are right. By the way, I'm not a Perl expert, but apparently it's possible to use a hash map instead, like in ulib.in.

[IceMan]

Replying to zaytsev:

It seems that you are right. By the way, I'm not a Perl expert, but apparently it's possible to use a hash map instead, like in ulib.in.

uzoo helper uses shell+awk instead of perl and I do not find another way to initialize associative array in awk.

[zaytsev]

Ah, sorry, my bad, I thought it's Perl. I've seen a hack in uace.in, but I think your version is better.

P.S. Another interesting case for testing. Ideally, we'd need to have sample data for all extfs formats and test all documented methods against this data... it is curious that date processing in zoo wasn't touched since the original commit in 1998; it would be interesting to bisect at which point it got broken and nobody noticed.

[mooffie]

I tested @IceMan?'s patch and can confirm that it works.

(BTW, zoo doesn't print localized month names, so using English names is ok.)

I'm attaching a patch to fix the documentation. The patch does not touch any code.

As for the "Mon DD YYYY hh:mm" format:

We did support this format in the past, plus "Mon DD hh:mm YYYY", but these two were removed in January 2006 (commit 8dfd1a2e4) to prevent an ambiguity problem (which I explain in the patch). That's the point the zoo filesystem got broken.)

BTW, we have 3 more filesystems using this obsolete format:

• hp48+
• uace
• uarc

[zaytsev]

@mooffie, oh wow, excellent work! Now, anyone up to taking the other 3 VFSs ;-) ?

[mooffie]

Replying to zaytsev:

@mooffie, oh wow, excellent work! Now, anyone up to taking the other 3 VFSs ;-) ?

Filed #3729.

[mooffie]

(In #3730) (Since this ticket includes a test for uzoo, it's dependent on #3696.)

[andrew_b]

Branch: 3696_uzoo_datetime_format
Initial changeset:072c6a82a244a1a42703888be108014e37d68159

[zaytsev-work]

Thank you mooffie and IceMan?!

[andrew_b]

Merged to master: [4b28a7e76ee867ef69d214e40d3d1b1d8825714b].

git log --pretty=oneline f2051b2..4b28a7e