7-Zip is gaining popularity because it generally gets better compression than both gzip and bzip2. I suggest we include the POSIX port of it (p7zip) with Haiku in the /bin folder.
Any thoughts?
j_freeman wrote:
7-Zip is gaining popularity because it generally gets better compression than both gzip and bzip2. I suggest we include the POSIX port of it (p7zip) with Haiku in the /bin folder.Any thoughts?
On my windows machines - I use the 7zip GUI client exclusively now. It even compresses plain zip files better than most - I use the 7z format for anything I don’t intend to send to others.
one concern with archivers on BFS volumes – properly archiving BFS Attributes. To the best of my knowledge only zip properly archives attributes. Does anyone know offhand if only the zip program supplied with BeOS can do this or if all zip programs are capable?
Aside from that, imo Haiku should include at least support for decompressing as many types of archives as possible. Some small CLI programs, a few lines in expander’s rules, and maybe some additional mimetype magic is all that’d be needed.
Then for users who want a very nice and functional archive manager, Beezer is freely available.
umccullough wrote:
j_freeman wrote:7-Zip is gaining popularity because it generally gets better compression than both gzip and bzip2. I suggest we include the POSIX port of it (p7zip) with Haiku in the /bin folder.Any thoughts?
On my windows machines - I use the 7zip GUI client exclusively now. It even compresses plain zip files better than most - I use the 7z format for anything I don’t intend to send to others.
Same here. I use 7-Zip (for Windows) exclusively for all my archiving needs.
mmadia wrote:
one concern with archivers on BFS volumes -- properly archiving BFS Attributes. To the best of my knowledge only zip properly archives attributes. Does anyone know offhand if only the zip program supplied with BeOS can do this or if all zip programs are capable?
I’m pretty sure bzip2 doesn’t handle attributes, either. On Linux, to keep the file permissions intact, you must tar the file(s) before compressing them. Works the same with 7zip.
I’m not sure if a tarball would keep the BFS attributes intact like it does with Linux file permissions; maybe someone reading this on BeOS can quickly tarball some files and see if it keeps everything. If it works, we’d just use 7z like bzip2: filename.tar.7z
j_freeman wrote:
umccullough wrote:j_freeman wrote:7-Zip is gaining popularity because it generally gets better compression than both gzip and bzip2. I suggest we include the POSIX port of it (p7zip) with Haiku in the /bin folder.Any thoughts?
On my windows machines - I use the 7zip GUI client exclusively now. It even compresses plain zip files better than most - I use the 7z format for anything I don’t intend to send to others.
Same here. I use 7-Zip (for Windows) exclusively for all my archiving needs.
mmadia wrote:one concern with archivers on BFS volumes -- properly archiving BFS Attributes. To the best of my knowledge only zip properly archives attributes. Does anyone know offhand if only the zip program supplied with BeOS can do this or if all zip programs are capable?I’m pretty sure bzip2 doesn’t handle attributes, either. On Linux, to keep the file permissions intact, you must tar the file(s) before compressing them. Works the same with 7zip.
I’m not sure if a tarball would keep the BFS attributes intact like it does with Linux file permissions; maybe someone reading this on BeOS can quickly tarball some files and see if it keeps everything. If it works, we’d just use 7z like bzip2: filename.tar.7z
tar doesn’t preserve BFS attributes.
info-zip provide zip does, only by specific patches to do it so having been accepted in the era when info-zip were a lot more active. Any other zip compressor ported to BeOS does not (not that any have been, to the best of my knowledge…)
So BFS attribute preservation isn’t part of the standard zip format? And tarball doesn’t preserve BFS attributes either? Well… that just sucks. 
We still need to have native support (i.e. command-line utils) for the popular compression schemes: zip, rar, gzip, bzip2, and 7z. Zip really is one of the least preferred formats nowadays, yet it seems to be the de facto for BeOS.
Maybe we could modify 7zip to preserve BFS attributes. But would archives made with this modified 7zip be readable under standard-7zip programs? Obviously they wouldn’t read the BFS attributes, but would everything else decompress fine? (All statements and questions in this paragraph should be applied to all the other formats as well.)
Quote:
Maybe before we should talk with 7zip author about adding extended attributes to the format?
Maybe we could modify 7zip to preserve BFS attributes. But would archives made with this modified 7zip be readable under standard-7zip programs? Obviously they wouldn't read the BFS attributes, but would everything else decompress fine? (All statements and questions in this paragraph should be applied to all the other formats as well.)
j_freeman wrote:
Zip really is one of the least preferred formats nowadays, yet it seems to be the de facto for BeOS.
And Windows. And MacOS X.
Its whats used, by default, on any system where theres a large amount of users that don’t like being disturbed by changing what they do by default every year, basically.
MYOB wrote:
j_freeman wrote:Zip really is one of the least preferred formats nowadays, yet it seems to be the de facto for BeOS.And Windows. And MacOS X.
Its whats used, by default, on any system where theres a large amount of users that don’t like being disturbed by changing what they do by default every year, basically.
That was… pretty much my point; that Zip’s only strength is that it’s so widely available and used, and that it’s only widely available and used because it’s so widely available and used.
I didn’t know the BeOS experience was about using the most widely-available formats simply because they’re widely-available. Afterall, BeOS/Haiku dumps screenshots in the PNG format, not the GIF format. PNG might be popular nowadays, but during the days of R5 it definitely was not. The engineers chose the format because it was much more appropriate for screenshots, not because it was widely used.
But I digress…
michalg wrote:
Quote:Maybe before we should talk with 7zip author about adding extended attributes to the format?Maybe we could modify 7zip to preserve BFS attributes. But would archives made with this modified 7zip be readable under standard-7zip programs? Obviously they wouldn't read the BFS attributes, but would everything else decompress fine? (All statements and questions in this paragraph should be applied to all the other formats as well.)
I’m not sure. Asking him wouldn’t hurt I suppose, but I doubt he’d put it on any priority. The 7-zip program is Windows-only; other platforms must use the POSIX-port which is maintained by a third-party developer. If he doesn’t even release an official version of his program for other OSes, why would he implement features that would only benefit other OSes? Though, I believe he is one of the two developers that maintain the 3rd-party port, so maybe there’s a chance?
michalg wrote:
Quote:Maybe before we should talk with 7zip author about adding extended attributes to the format?Maybe we could modify 7zip to preserve BFS attributes. But would archives made with this modified 7zip be readable under standard-7zip programs? Obviously they wouldn't read the BFS attributes, but would everything else decompress fine? (All statements and questions in this paragraph should be applied to all the other formats as well.)
or maybe come up with a way that attributes would be stored in an additional file that is compressed along with the file they belong to with a special name, etc. probably something to think about for R2 though.
I use 7-zip exclusively too and alot of torrents have been
starting to use it too being one of the highest if not the
the highest compressor there is (not just in its own format)
intergrating it into the standard /bin set of apps
would be great even if someone has to do some work
to get it to support beos conventions
or even commandline arguments so it works
like the rest of the apps on the system
its a great program if someone could contact the other
about it ^^
and it supports most formats so if it got ported
we’d have all the compression format we’d really need
in one great commandline app
and it does the formats better than most of the programs
that started them =P
umccullough wrote:
michalg wrote:Quote:Maybe before we should talk with 7zip author about adding extended attributes to the format?Maybe we could modify 7zip to preserve BFS attributes. But would archives made with this modified 7zip be readable under standard-7zip programs? Obviously they wouldn't read the BFS attributes, but would everything else decompress fine? (All statements and questions in this paragraph should be applied to all the other formats as well.)or maybe come up with a way that attributes would be stored in an additional file that is compressed along with the file they belong to with a special name, etc. probably something to think about for R2 though.
The UTAR extension to the tar format allow for some degree of custom metadata from my brief look at them, perhaps we could implement this functionality and get everyone to tar everything before compression? This way the compression scheme makes absolutely no difference to the outcome (Otherwise we’ll be forever extending new formats as they are created).
at that point, why not zip everything at a storage compression level before 7z, bz2, gz, etc., ?
That’s a good idea, works right now no problems 
The only potential (minor) downside I can see is that it could be slightly annoying for users of other operating systems; They could get a tad confused at foo.zip.bz2 (Well, their software may not automagically uncompress the embedded zip). Anyway, I’m all for your idea.
thanks, but i meant it sarcastically / rhetorically. 
imho, i wouldn’t do it because it’s cumbersome.
If a rule for Expander could processes foo.zip.$ext , while at the same time being able to handle bar.zip and bq.$ext, then it might be decent for that particular system. But there is no guarantee that everyone else’s exander.rules file would be contain those rules.
on the other hand, if bzip2, 7zip, rar, et al were modified to support attributes, would the other end-user need the updated versions to extract the attributes? ( in regards to other BFS capable OS’s ) if so, i don’t see how that’d be any better or worse than additional expander rules.
… after some quick fiddling, UnZip 5.40 of 28 November 1998 does not support decompressing from stdin.
funzip works with stdin, but only decompresses the 1st file. :?
Actually, I like eNIGMa’s idea of modifying the TAR format. Users are pretty much used to seeing .tar.bz2, etc. It’s not the most pleasant option, but I think it’s the most practical.
The functionality could definitely be added to expander to handle these different formats as needed; just a degree of how much effort we want to put into this.
I envision a time when all the major formats have built-in support for BFS attributes, but I don’t see that happening anytime soon. So until then, I envision we have a command-line app for each format (and this, we already practically have) and then simply modify our Expander to use the appropriate console-app(s) as needed when uncompressing a given file.
Quote:
on the other hand, if bzip2, 7zip, rar, et al were modified to support attributes, would the other end-user need the updated versions to extract the attributes? ( in regards to other BFS capable OS's ) if so, i don't see how that'd be any better or worse than additional expander rules.
I’d assume that they would indeed need special versions too, even if just extracting. But… isn’t that what we already have with Zip files? If I want to preserve BFS attributes on Windows, I need an unZip program that supports our modified format, otherwise the attributes are lost but the main contents are still extractable. I wouldn’t see it as any better, but I do see it as a worse solution: we’d have to maintain special versions of every compression/archive format instead of just one.
Any thoughts? Whatever is decided, we absolutely need "stock" support for the major compression and archive formats. I don’t want us to be like Windows and only have stock support for Zip.
The good thing about using UTAR is that it’s backward compatible IIRC, so it neatly sidesteps the issue of Haiku specific builds. I’ll have to have a bit more of a look again in the next few days…
j_freeman wrote:
... isn't that what we already have with Zip files? If I want to preserve BFS attributes on Windows, I need an unZip program that supports our modified format, otherwise the attributes are lost but the main contents are still extractable.
Attributes exist only on BFS partitions. As soon as a file is placed on another filesystem, the attributes have no place to reside and are lost. Try copying an email file (or any file with attributes) to FAT32 and back to BFS and then look for the attributes.
mmadia wrote:
Attributes exist only on BFS partitions.
Lots of other filesystems support attributes. For a start, NTFS, ext3, XFS and ZFS. They vary in their exact feature set, and in the available APIs, but they’re all capable of storing arbitrary metadata in named attributes of a file.