[Midnight Commander] #4558: Part of a bigger problem: impossible to add an executable file to a 7z archive
Ticket System
archive
--------------------------------+------------------------------
Reporter: ponko | Type: defect
Status: new | Priority: major
Milestone: Future Releases | Component: mc-vfs
Version: master | Keywords:
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
--------------------------------+------------------------------
I have a 7z archive: '''/run/shm/1.7z'''. I open it in the left panel,
open '''/bin''' in the other panel and copy '''base64''' to the archive.
The file gets added to the archive, but as a regular file, NOT as an
executable one.
The evident problem is such command used in the '''u7z''' extfs script to
add the file:
{{{
7z a -si"$2" "$1" <"$3" >/dev/null 2>&1
}}}
This command takes file data from stdin and, evidently, information about
file permissions/mtime is lost.
But there is one more problem. On copying the file into the archive, u7z
gets such args:
{{{
copyin /run/shm/1.7z base64 /tmp/user/1000/mc-user/extfsOVJKQ2base64
}}}
The temp file has perms 600 and is touched with the current time. So, no
matter if u7z feeds 7z from stdin or not, there is no way for it to see
the original file perms and mtime.
I think, when the extfs (or vfs?) core creates a temp file to feed it to
the copyin action, the temp file should have the same perms and mtime as
the original.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4558>
Midnight Commander <https://midnight-commander.org>
Midnight Development Center
Ticket System
archive
Reporter: ponko | Owner:
Type: defect | Status: new
Priority: major | Milestone: Future Releases
Component: mc-vfs | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by zaytsev):
This is weird, in some other scripts care is taken to preserve the
permissions while copying or using a symbolic link (see `uar.in` for a
good example). Are you sure that the temp file has wrong permissions and
it doesn't work with other archivers as well?
--
Ticket URL: <http://www.midnight-commander.org/ticket/4558#comment:1>
Ticket System
archive
Reporter: ponko | Owner:
Type: defect | Status: new
Priority: major | Milestone: Future Releases
Component: mc-vfs | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ponko):
{{{
mcarfs_copyin ()
{
TMPDIR=`mktemp -d "${MC_TMPDIR:-/tmp}/mctmpdir-uar.XXXXXX"` || exit 1
name=`basename "$2"`
(cd "$TMPDIR" && cp -fp "$3" "$name" && $XAR r "$1" "$name")
rm -rf "$TMPDIR"
}
}}}
It works directly on $3, but $3 is a temp file created by extfs/vfs core
and it always has perms 600, no matter the original perms. I just tried it
in an archlinux docker container. I added `echo "$@" >> /tmp/log` into the
copyin functions in u7z and uar.
After adding a file to a 7z and an ar archives I've got this under
$MC_TMPDIR:
{{{
# ls -l
total 8
-rw------- 1 root root 36 Jul 9 09:22 extfs21SQQ27z
-rw------- 1 root root 36 Jul 9 09:22 extfsQFRIQ27z
}}}
and this in the log
{{{
# cat /tmp/log
/tmp/1/1.7z 7z /tmp/mc-root/extfsQFRIQ27z
/tmp/1/archive.a 7z /tmp/mc-root/extfs21SQQ27z
}}}
See? In both cases, $3, fed to the copyin action, has perms 600. The
original file was 755.
--
Ticket URL: <http://www.midnight-commander.org/ticket/4558#comment:2>
Ticket System
archive
Reporter: ponko | Owner:
Type: defect | Status: new
Priority: major | Milestone: Future Releases
Component: mc-vfs | Version: master
Blocked By: | Blocking:
Branch state: no branch | Votes for changeset:
Comment (by ponko):
In the /tmp/log above "7z" is the file I added to the archives (/bin/7z).
Should have used another binary to copy in, it looks confusing as such in
the log
--
Ticket URL: <http://www.midnight-commander.org/ticket/4558#comment:3>