Ticket #4191 (closed defect: fixed)

Opened 3 months ago

Last modified 2 months ago

4.8.26: unable to browse tar.xz

Reported by: onlyjob Owned by: andrew_b
Priority: major Milestone: 4.8.27
Component: mc-core Version: 4.8.26
Keywords: Cc: onlyjob@…
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

Just released MC-4.8.26 is unable to enter tar.xz archives like the MC's own release tarball: "Cannot open tar archive mc_4.8.26.orig.tar.xz/uxz://".

MC-4.8.25 was able to do that successfully. tag.gz is OK, only tar.xz is affected as far as I can tell...

Change History

comment:1 Changed 3 months ago by andrew_b

  • Status changed from new to closed
  • Resolution set to invalid
  • Milestone Future Releases deleted

This is the result of #4128. You should synchronize your local ~/.config/mc/mc.ext with system-wide /etc/mc/mc.ext.

See also #4180, #4183.

comment:2 Changed 3 months ago by onlyjob

  • Status changed from closed to reopened
  • Cc onlyjob@… added
  • Resolution invalid deleted

No I think it is a different issue.
For several years I have XZ_OPT environment variable set as follows:

XZ_OPT=-6v

Before 4.8.26 that was not causing any problems...

MC-4.8.26 can enter .tar.xz archives if started as follows:

XZ_OPT="" mc

comment:3 Changed 3 months ago by andrew_b

MC doesn't know anything about XZ_OPT.

comment:4 Changed 3 months ago by andrew_b

Before 4.8.26:

$ file -L test.tar.xz 
test.tar.xz: xz compressed data

4.8.26:

$ file -L -z test.tar.xz 
test.tar.xz: POSIX tar archive (GNU) (xz compressed data)

Please update your ~/.config/mc/mc.ext.

comment:5 Changed 3 months ago by onlyjob

Of course I did update my mc.ext, as advised, and could reproduce the problem still - that's why I've re-opened the issue.

XZ_OPT modifies output of the xz. I think MC is confused by "-v" part that prints extraction progress to STDERR. Formerly STDERR was captured, presented to user and I had to dismiss it with a brief keystroke, but it did not cause failure hence former behaviour was more robust.

comment:6 Changed 3 months ago by zaytsev

That's weird, I can't remember any patches messing with stderr - probably need to blame.

comment:7 Changed 3 months ago by andrew_b

comment:8 Changed 3 months ago by onlyjob

Thank you for troubleshooting, Andrew.

comment:9 Changed 3 months ago by andrew_b

  • Owner set to andrew_b
  • Status changed from reopened to accepted
  • Branch state changed from no branch to on review
  • Milestone set to 4.8.27

comment:10 Changed 3 months ago by ossi

that's some bizarre code. why not use dup2 properly right away?

comment:11 Changed 3 months ago by andrew_b

  • Branch state changed from on review to on rework

comment:12 Changed 2 months ago by andrew_b

  • Branch state changed from on rework to on review

Read of stdout/stderr of child process is reimplemented using mc_pipe engine.

Branch: 4191_tar.xz
Initial changeset:99ac6d4207f5f7072b3524eeeb742ff657aef9ba

comment:13 Changed 2 months ago by ossi

is there a way to sensibly comment on the patches? i really don't feel like specifying the sha1, file, and line number for every issue i see ...

comment:15 Changed 2 months ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:16 Changed 2 months ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

Merged to master: [318981535fb9e6d6dd2c4b25b72cae4d7a1fd13e].

git log --pretty=onelin ff0949ece..318981535

comment:17 Changed 2 months ago by andrew_b

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.