Files packed from STDIN have no attributes
A free file archiver for extremely high compression
Brought to you by:
ipavlov
On Linux, files in 7z archives packed from STDIN have attributes at all.
Expected behavior is to have default attributes: 664 (-rw-rw-r--)
P.S.
There a few bugs on GitHub but activity.
If issues there are ignored maybe issue tracked should be disabled there and redirected here.
So what is Expected behavior?
Can you test another programs in Linux fot same thing?
you can look attributes for another created archives so:
Last edit: Igor Pavlov 2024-02-05
Thank you for responding so quickly.
Please find below the log of my testing.
I've included a few examples of expected behavior for reference.
Please note that only the file extracted from the archive created using STDIN has no attributes at all
----------
while in all other examples it has default attributes-rw-rw-r--
.$ 7z l -slt data.rar
$ 7z x data.rar
$ ll 0.data
-rw-rw-r-- 1 username username 4096 Feb 2 2001 0.data
$ 7z a data.file.7z 0.data
$ 7z l -slt data.file.7z
$ 7z x data.file.7z
$ ll 0.data
-rw-rw-r-- 1 username username 4096 Feb 2 2001 0.data
$ cat 0.data | 7z a -si 0.data.7z
$ 7z l -slt 0.data.7z
$ 7z x 0.data.7z
$ ll 0.data
---------- 1 username username 4096 Feb 5 11:32 0.data
$ 7z x data.file.7z
$ ll 0.data
-rw-rw-r-- 1 username username 4096 Feb 2 2001 0.data
$ cat 0.data | xz > 0.data.xz
$ 7z l -slt 0.data.xz
$ 7z x 0.data.xz
$ ll 0.data
-rw-rw-r-- 1 username username 4096 Feb 5 11:37 0.data
$ xz -d -f 0.data.xz
$ ll 0.data
-rw-rw-r-- 1 username username 4096 Feb 5 11:37 0.data
the question is about programs like rar,tar,cpio,zip that can store attribute.
And if these programs can read input data from stdin, what exact properties they writeto archive?
So we must create more archives from stdin with different programs.
And then we can look "7z l -slt arc" for them to check what exact value they write.
We can write any of these:
777
775
755
666
664
644
what way is better?
Last edit: Igor Pavlov 2024-02-05
There is an example of XZ in my log
cat 0.data | xz > 0.data.xz
.I just retested with XZ, Bzip2, Gzip and ZSTD and they all do the same, they give the output file default permissions 644
Tar, CPIO, rar zip etc are not compressors and are not expected to work with STDIN/STDOUT.
7Zip is an exception in that regard due to it's universality ;-)
XZ, Bzip2, Gzip and ZSTD can not be used as example, because they do not store file "mode" attributes.
"7z l a.xz -slt" doesn't show any mode value.
TAR ZIP RAR CPIO XAR can be used, because they store some "mode" value.
"7z l a.zip -slt" shows mode value.
tar and cpio expect a file list and can not accept STDIN.
I could not analog for 7z's -"si" parameter for rar and zip.
Not sure about XAR.
7z is unique by supporting "-si".
Judging by behavior of all other compressors, 7z should assign default file permissions to files in archive that were "sourced" from STDIN.
zip writes as
777
mode:and empty attributes in rar as I suppose in rar.
But probably we can get more examples.
If we can't get more examples, maybe I can use
777
as in zip.Last edit: Igor Pavlov 2024-02-05
777 is the default for Windows oriented tools this is why Zip and Rar on Windows behave this way.
On Unix 777 makes the file executable and readable/writable by everybody which is not ideal.
Just tested Rar with -si, and it stores files in archive as 644 so ideally 7z -si should do the same.
Also 7z does the same when storing regular files so it is consistent with existing behavior.
Last edit: eugenesan 2024-02-05
rar doesn't stores 644.
your tests were incorrect.
Note that there are different things:
1) the value stored in archive
2) the value that set in filesystem when archive is extracted.
These values are not same.
The question is what value to store to archive.
zip stores 777
rar stores nothing (probably).
p7zip stores nothing (probably).
7-zip stores 000. and it can be problem.
(000 != nothing)
We can store nothing or
777
or some other value.On my system with command line you've provided for RAR, it behaves as I showed earlier.
Maybe different versions of RAR behave differently?
It's not.
Default is 644 (-rw-r--r--) for files and 755 (drwxr-xr-x) for directories.
It is controlled by umask (1), which is 0022 by default.
You can either set it to 644 by default, or read default file mask and set permissions accordingly.
P7zip does not set in-archive attributes at all and newly created files use default mask.
Maybe that's the way to solve it, to let the system 'decide' what is default mode. Or, as said before, to read default mask and apply it to get default mode.
Rar calls file 'stdin' and set mode to 0, which is the same as 7zz now.
and info zip calls it '-' and does its onw thing.
Last edit: Sam Tansy 2024-02-06
Extract command is not important for as now.
Create archive comand and "7z l -slt" are important only.
Extracting can change attributes.
Now we think about stored value only.
Last edit: Igor Pavlov 2024-02-05
Rar does not store any attributes.
It does its own, IMO wrong, thing during unpacking and creating a file.
Zip does.
It (zip) probably has to as they are 'static' and left unset would be zero anyway.
It marks it as 'p', which I guess is 'pipe'. That could be a clue if 7zip had that attribute.
Last edit: Sam Tansy 2024-02-05
I see.
Rar probably displays default permissions for the host system when attributes are empty and sets default permissions on extraction.
I guess 7zip should do the same.
It rather shows cleared attributes, name 0x000...
Rather sets zero, not default, to newly created file. Default would be 644.
This what I see when testing with RAR 6.23 on Linux
$ cat 1.txt | rar -si a 2.rar
$ rar l 2.rar
$ rar x 2.rar
$ ll stdin
Different version of rar: v5.91.
And, as you can see, rar set whatever it stored, rather than create new one and not change the system defaults.
Last edit: Sam Tansy 2024-02-05
Indeed. Seems like Rar 6.x behaves more "Unixy" ;-)
$ rar l stdin.rar5
And it seems like Rar deals with the problem when packing and not when extracting:
$ rar x stdin.rar5
$ $ ll stdin
Last edit: eugenesan 2024-02-05
Zip too.
P7zip, does not store anything and does not set anything on creation.
Also setting attributes while packing makes sense that file with zeroed attributes could not be added to archive.
Unless you're root/admin, then it could. But that's nonsense to assume that user is administrator.
Last edit: Sam Tansy 2024-02-06
Mimicking p7zip behavior sounds good, especially since majority of recent Linux distributions switched to 7zip 23.01 from p7zip 16.02.
Either approach will work as long as resulting files/dirs have sane permisions (644/755).
Choose the the method that is easier to implement.
FYI:
This is the script that is packaged with 7zip to mimics p7zip's behavior: https://salsa.debian.org/debian/7zip/-/blob/master/debian/scripts/p7zip.sh
I have tested rar again.
it writes
DT_UNKNOWN
instead ofDT_REG
to bits 12-15 of properties:Probably I'll not write attribute properties to 7z archive, because it's possible to create 7z archive without attributes metadata.
But we still neeed some value for zip archive.
So we can write
DT_REG
and777
to zip in high 16-bits of 32-bit value.Last edit: Igor Pavlov 2024-02-06
With zip you may do what zip does - mark it as pipe and write mode as would local umask apply.
But it should obey local umask not hardcoded 0066, that would produce mode 600.
IMO, It should look like this: