Ticket #4191 (closed defect: fixed)
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 years ago by andrew_b
- Status changed from new to closed
- Resolution set to invalid
- Milestone Future Releases deleted
comment:2 Changed 3 years 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:4 Changed 3 years 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 years 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 years ago by zaytsev
That's weird, I can't remember any patches messing with stderr - probably need to blame.
comment:7 Changed 3 years ago by andrew_b
Bad commit is [61f997de269d4dcfb89ab674d6730bba7f38b1fe].
comment:9 Changed 3 years 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
Branch: 4191_tar.xz
Initial changeset:a5036e0256f9041f2f42345778388cdb6bcda83f
comment:10 Changed 3 years ago by ossi
that's some bizarre code. why not use dup2 properly right away?
comment:12 Changed 3 years 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 3 years 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:14 Changed 3 years ago by andrew_b
comment:15 Changed 3 years ago by andrew_b
- Votes for changeset set to andrew_b
- Branch state changed from on review to approved
comment:16 Changed 3 years 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
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.