7-zip 22.00 – APFS, Posix TAR, high precision timestamps
sourceforge.net
sourceforge.net
[1] https://blogs.windows.com/windowsdeveloper/2021/07/19/extend... [2] https://github.com/M2Team/NanaZip
Yes you can click "Show More Options" as well, but I find the drag operation much faster once you get the habit down.
> Due to the policy from Microsoft Store, NanaZip is unable to disable Desktop Bridge file system virtualization, so the file operations in %UserProfile%/AppData will be redirected in Windows 10, and file operations in directories other than Local, LocalLow and Roaming in %UserProfile%/AppData will still be redirected in Windows 11.
> Due to the Microsoft Store limitations, NanaZip 1.2 and later won't support languages not mentioned in https://docs.microsoft.com/en-us/windows/uwp/publish/support....
As usual, sandboxing is a downgrade.
What does that mean?
https://docs.microsoft.com/en-us/sysinternals/downloads/auto...
Explorer tab, anything under ContextMenuHandler keys.
The whole argument is bogus anyhow - if win11 wanted to avoid orphaned context menu registrations, then it makes sense to tie those to installed programs. However, that has nothing to do what's nested and what's not.
Yes, windows should likely make it easier to declutter the contextmenu, and yes, that may require a new api. But the new interface is still a really poor choice even assuming those are givens.
I'm curious which options in the new context menu you actually use most often? Clearly your usage is quite different from mine.
Keka (or Unarchiver) on macOS and PeaZip on Windows are the nicest decompressors, in terms of UX, I know. Not sure about Linux.
There are some strange builtin entries from Windows. Like why do I have the option to "play" a jpeg on any Bluetooth headsets that are paired with my laptop? I just found out that besides "open with" and "send to" there is a third way to open a file using "share" to share a file with an app.
The most useless entry is probably from AMD Radeon software. Two entries on the very top of the context menu on every folder. I would understand if it appeared in the menu of the Desktop folder, but not on every single folder no matter how deep in the file structure.
Just clean out the entries you don't need. Blame microsoft if that means having to dig into the registry.
This is the whole point to why Microsoft took this awkward step.
You can make the case for a new API to avoid orphaning, and for greater traceability - and also, hopefully, for better performance. But I sure hope the end result will be more usable not less, and I'm pretty disappointed that this intermediate step is such a step backwards.
I searched a lot but couldn't find this "7zz" package you mentioned.
https://packages.ubuntu.com/jammy/p7zip
That one hasn't seen new releases since 2016.
The 7zz refers to the new binary name, which is different between the p7zip and 7zip packages.
That's interesting, thanks.
From time to time customers ask about adding "7zip" to the environment at rsync.net so that they can do things like:
ssh user@rsync.net 7z blah blah ...
I see that source is available so we should be able to compile it for FreeBSD without too much trouble ... I'll write up something in next quarters tech notes about it ...
They provide a statically linked version (7zzs) that works on things like Alpine Linux.
Not being able to use perfectly normal strings like aux or nul as filenames is of course an entirely different category of madness.
> How the hell is that acceptable in 2022?
Because Microsoft is hell bent on backwards compatibility.
in any case, kudos to the continued development, this is one of my favorite pieces of software, no web bloat, just a very solid piece of engineering of a native application.
I'd very much like to see more of these, instead of turning nowadays everything into a web app, I really find them unbearable most often, to the point that I even choose to use native software that's no longer maintained, if there's no other alternative to an electron/web resource hog, which are as far from snappiness as possible.
I've also seen yyyy.increment.build
Then 16.02,16.03,16.04 , 17.00, 17.01, 18.00
These jumps don't correlate with major changes and major versions
[1] https://sourceforge.net/projects/sevenzip/files/7-Zip/
[2] https://sourceforge.net/p/sevenzip/discussion/45797/thread/9...
It's still in development?!?!
A killer's filesystem, rather.
.
.
.
(tiny download link)
For the rest of us, this is expected behaviour, and I don't want 7z special-casing exes or always extracting all files in an archive just to open one.
This seems the expected and reasonable behavior to me, as a second data point.
7zip is good for extracting archives somewhere and for supporting a ton of archive formats (and especially for supporting disk image formats!) but as an archiving tool its features are barely barebones.
Which is basically why on Windows i tend to have both installed - WinRAR for being an actually good (and very fast) archiving tool and 7zip for handling the archives WinRAR cannot handle.
(though nowadays i handle most archives via Total Commander - which i use even on Linux via Wine :-P - which asks you if you want to either extract just a single file or all files in the archive and is IMO the best approach anyway)
Anyone know if this is open source, and where the sources are supposed to be?
You may prefer the development to be in the open and that is fair (I do too) but don't mislabel things because of that.
"Probably" because some projects like this don't actually include all parts of the source. FreeFileSync for example which claimed to be opensource, and they distributed some source, did in fact lack many parts, not just build files but actual source files (I think it can be built nowadays however).
The big problem here isn't that you don't have a commit history. It's that these programs are often unbuildable. And often it seems that they are purposely distributed this way to deter other people from building or forking your software.
Again however, I haven't actually checked the source files provided by 7zip in particular, but this problem I describe is a very common pattern in software whose source is distributed this way.
huh?
$ tar tvzf test.tar.gz
These programs can list the files in the archive, but I have never found an easy way to extract specific files without having to type paths on the command line, or use a filelist (something like tar xf 1.tar -T list which zip utilities generally cannot do).
Until I am advised of something better, a quick and dirty solution:
usage: 1.sh 1.zip # displays list of files with line numbers
1.sh 1.zip 5p # extracts the file listed on line 5 to stdout
1.sh 1.zip 5,6p # extracts the files listed on lines 5 and 6 to stdout
1.sh 1.zip 5p\;8p # extracts the files listed on lines 5 and 8 to stdout
1.sh 1.zip /src/ # extracts the files with "src" in their path to stdout
case $# in :)
;;1)exec 7z l $1|sed -n '/^---/,/^---/{/^---/!p;}'|cat -n
;;2)
y=$1
shift
x=$(7z l $y|sed -n "/^---/,/^---/{/^---/d;s/.* //p;}"|sed -n "$@")
7z x -so $y $x
exec echo
;;0|*)exec echo usage: $0 zip-file \[sed cmd\]
esac;This says its still open, disputed, and not a 7-zip issue exactly: https://sourceforge.net/p/sevenzip/bugs/2340/
Would be nice to know if or how 7-zip plans to address this. Patch management tools are going to call this a vulnerability until there is some resolution.
[1]: https://en.wikipedia.org/wiki/Error_correction_code#Forward_...
I've seen so many support questions related to people using 7zip to untar things
All the script targets are hard-linked together, and the the tar needs to be created as 7za's standard input with -si, not as a file.
$ cat ~/bin/7ctar
#!/bin/sh
zfile=$1
shift
case ${0##*/} in
7ltar) 7za x -so "$zfile" | tar tvf - "$@" ;;
7xtar) 7za x -so "$zfile" | tar xvf - "$@" ;;
7ctar) tar cvf - "$@" | 7za a -mx=9 -si "$zfile" ;;
esac
$ 7ctar test.tar.7z /etc/passwd /etc/group /etc/hosts
tar: Removing leading `/' from member names
/etc/passwd
/etc/group
/etc/hosts
...
$ 7ltar test.tar.7z
-rw-r--r-- root/root 3774 2021-11-17 12:52:56 etc/passwd
-rw-r--r-- root/root 948 2019-08-08 09:52:52 etc/group
-rw-r--r-- root/root 242 2017-08-31 09:57:40 etc/hosts
$ ../7xtar test.tar.7z
etc/passwd
etc/group
etc/hostsBy nature of being so ancient, it's had limitations that had to be expanded and patched around across different systems.
Is this OpenSource ?
It still won't guarantee you get to skip the bad smartscreen prompt, though.
And it won't instantly skip SmartScreen (that requires EV which is $300+) but it helps to establish reputation, i.e.: if you consistently release safe software signed with a cert named X, then SmartScreen and co. learn to give a good starting reputation to binaries signed by X.
> The Linux Foundation, Red Hat, Google, and Purdue have unveiled the free 'sigstore' service that lets developers code-sign and verify open source software to prevent supply-chain attacks.
> As demonstrated by the recent dependency confusion attacks and malicious typo-squatted NPM packages, the open-source ecosystem is commonly targeted for supply-chain attacks.
> To pull these attacks off, threat actors will create malicious open-source packages and upload them to public repositories using names similar to popular legitimate packages. If a developer mistakenly includes the malicious package in their own project, malicious code will automatically be executed when the project is built.
> To prevent these types of attacks, 'sigstore' will be a free-to-use non-profit software signing service that allows developers to sign open-source software and verify their authenticity.
> "You can think of it like Let’s Encrypt for Code Signing. Just like how Let’s Encrypt provides free certificates and automation tooling for HTTPS, sigstore provides free certificates and tooling to automate and verify signatures of source code."
[1] https://www.bleepingcomputer.com/news/security/linux-foundat...
Not available to us plebs and vague enough that it isn't even clear if they provide Windows-compatible code signing certs.
Fuck that. 7-zip.org has official download links - you can expect those to be the official binaries from 7-zip.org - and a code sigining certificate won't really tell you more than that.
If you want Microsoft to gatekeep your software then please complain to Microsoft if that inconveniences you, not to anyone else.
> 7-zip.org has official download links - you can expect those to be the official binaries from 7-zip.org - and a code sigining certificate won't really tell you more than that.
Have you heard of compromised download servers? At least signing it on your machine before distribution means you can guarantee it hasn’t changed. (And yes, you can just change the hash on the website, it’s the same server)
It's not had the best support for them, though, since it wouldn't always let you access the list of files in an archived tar. You often had to extract the tar to do that.
Obviously, that's not the answer a lot of open source developers want because of mistrust in the Store and Store distribution, but after years of all the complaints of the CA cartels and people asking for an alternative, Microsoft built an alternative (and no one came, lol).
[1] https://developer.microsoft.com/en-us/microsoft-store/regist...
Sourceforge's inclusion of spyware and malware in downloads, and the current owner's willful ignorance of racism and hate-speech in other publications (Slashdot) is not a sign of a serious company offering a serious service.
I have not used it since 2019, but at that point it was still rife with hate speech directed towards the chinese, the russian, and generally black and brown people.
And I do not have a curated journal of this ready for your inspection, you simply have to trawl the comments section yourself. That way you don't have to take my word for it.
How do you determine that comment curation that fails your own standards is "willful ignorance" on behalf of the owner?
And I reported hundreds of comments with language like this over the years, and whenever I followed up on it I always found the comments still present in the discussion thread.
And even if you develop the perfect archive format that happens to nail every possible use-case 100% (which you won't, because there just are too many), you will STILL have to deal with compressed and archived artifacts which accumulated over the last six or so decades in various places.
That's a parallel universe far far away, ~99% of people having to use tar (just because it's the standard and the only format supporting links/access metadata) every day will never have to use a tape drive. I don't see a reason why we can't use 2 separate formats - one for everyday packaging, a different one for tape drives.
> And even if you develop the perfect archive format
There is a perfect format already - it's 7z. Just add file access rights and links support to it. No need to invent anything really new.
These two sentences seem to contradict each other.
By the way I have just found an actual imperfection in 7zip: it can't let you choose the order in which archived files are stored in it nor chose different compression parameters for specific files. This limits its applicability. E.g. the EPUB standard says the first file in an archive must be "mimetype" and it must be not compressed. But I believe this can be fixed with reasonable ease (and probably without breaking changes) as well.
Keeping these two tasks separate allows swapping-out the implementation of each (e.g. I tend to use .tar.lz these days, since I'm mostly on Unix)
On a related note I was surprised to discover that the Windows 10 backup tool was able to store about 240GB of various data in barely 80GB of backup; I believe it must have spliced most files to look for common fragment to deduplicate (with some NTFS magic behind maybe). .tar.xz will never be able to do that, if I try to compress 10 copies of the entire firefox codebase, it will never be able to recognize the duplicated files; only something like a file-system+compression could do that.
borg handles this just fine. I put all kinds of stuff into borg repositories: raw MySQL/PostgreSQL data directories, tar archives (both compressed and uncompressed), or just / recursively. You can do stuff like:
$ tar -caf - / | borg create …
$ borg create … </dev/sda
That's a vacuous statement, since there will never be a "general file-system representation format"; that's my point. Even if someone collected together all the features of every filesystem ever developed, that would still ignore those which haven't been invented yet.
Further, it requires a choice of which compression algorithm? What about those that haven't been invented yet?
These problems only arise if we want to define "one true archiver+compressor". If we keep these concerns separate, there's no problem: we choose/create a format for our data, and choose/create a compressor appropriate to our requirements (speed, size, ratio, availability, etc.)
> .tar.xz will never be able to do that, if I try to compress 10 copies of the entire firefox codebase, it will never be able to recognize the duplicated files; only something like a file-system+compression could do that
This seems to miss my point, in several ways:
Firstly, xz has a relatively small dictionary, so your use-case would benefit from an algorithm which detects long-range patterns. Choosing a different compression algorithm for a .tar file is trivial, since it's a separate step; whereas formats like 7zip, zip, etc. lock us in to a meagre handful of hard-coded algorithms. That's the point I'm trying to make.
Secondly, .tar is designed for storing what it's given "as is": giving it hardlinked copies of the Firefox source will produce an archive with one copy and some links, as expected; giving it multiple separate copies will produce an archive with multiple copies, as expected. That's not appropriate for your use-case, so you would benefit from a different archive format that performs deduplication. Again, you're only free to do this if you don't conflate archiving with compression!
In your case, it looks like a .wim.lrzip file would be the best combination: deduplicating files where possible, and compressing any long-range redundancies that remain. This should give better compression, and scale to larger sizes, than either .tar.xz or .7z
(Note that WIM seems to also make the mistake of hard-coding a handful of compression algorithms, so you'd want to ignore that option and use its raw, uncompressed mode. My brief Googling didn't find any alternative formats which avoid such hard-coding :( )
What I was trying to say is that .tar IS a filesystem description format; used to convert the filesystem into a stream that is then compressed separately.