I'm developing PeaZip project in FreePascal language, under Lazarus IDE. I like Pascal-related languages and I think Lazarus/FreePascal is one of the best cross-platform IDE available; I like it even more because it is open source and because it's growing day by day in a more mature and powerful IDE. I'll be glad to bring a bit of developer's attention on Lazarus/FreePascal through my project."
Delphi may be dead(*), but Lazarus/FreePascal is very much alive and kicking...
More power to you, oh-as-of-yet-unknown WinZip/WinRar open source replacement-writing author!!! <g>
This is correct, at least for excel and word (xlsx and docx, respectfully, dont know about the others). And past the zip, theyre both largely terse xml under the hood abiding by a published schema. This is actually pretty convenient and allows for cross platform tools for creating/consuming files. For instance, I like the xlsxwriter Python module for creating xlsx files (no affiliation with the project, but I've used it at a couple of jobs to create some pretty nice spreadsheets, with no need for an excel install on a server). A lot of early Python modules required an Excel install and worked over COM, so on both accounts, Windows only.
Yes, good points. I think (but not sure) that the change from MS Office binary file formats (with their issues of being proprietary, undocumented, etc.) to zipped XML formats (for Word, Excel, Powerpoint, etc.) came at the same time as when they added an "x" to the filename extensions, like changing .doc to .docx, .xls to .xlsx, and so on.
This was also probably around the time when there was that big public hoo-ha about MS XML formats vs. Open Office / Open Document formats. I had read some about it at the time, don't remember the full details.
I've been using PeaZip for years. Once I discovered that it didn't extract files to a temporary folder, then copy files to the destination from there (resulting in two needless file transfers), I haven't looked back.
> Once I discovered that it didn't extract files to a temporary folder, then copy files to the destination from there (resulting in two needless file transfers)
I believe they're saying a file archiver should _not_ do this, and that PeaZIP does _not_ do this.
> I haven't looked back.
I believe this means that they're happy with PeaZIP.
I don't know why any program would copy files, let alone twice, to un-archive them, but the usual extract-then-mv pattern is an important feature, usually well-worth the cost of the extra syscall: if the extraction is interrupted, it avoids leaving incomplete files that are indistinguishable from correctly-extracted files. I would consider extracting in place by default a design flaw.
Extract and move is fine, but many programs extract to a temp dir first, and then copy the file. I don't think anyone minds an extra rename (and, as you say, it gets you a sort of atomicity with the extract) but moving a file out of a temp dir can mean doing a full copy, if the destination is not on the same FS.
As a side note: for POSIX OS's, this is why I much prefer the FD based operations. I don't think it quite exists, but I really think the right answer here is to create a deleted file, and then give it a filename. That is, you write the data out to disk, and hardlink it into its final resting place. Atomic, but with no mess of figuring out a temporary name. This is the reverse of how temporary files work, where you create a temp file & then delete it, before writing to it. (Linux allows this; it'll clean up the file when it is closed. It's backed by disk, and since it lacks a name, it can't be inadvertently opened or messed with by other programs. It's a way of saying "give me anonymous disk space".) There's a syscall to create deleted files in one-shot, now, but I don't think there's a way to hardlink them, yet. (Note that you need to still provide either a path, or the FD to a directory, s.t. the OS can determine what FS should back the file, and that you have access to disk at all.)
> Extract and move is fine, but many programs extract to a temp dir first, and then copy the file. I don't think anyone minds an extra rename (and, as you say, it gets you a sort of atomicity with the extract) but moving a file out of a temp dir can mean doing a full copy, if the destination is not on the same FS.
The way many programs deal with this (Firefox, rsync by default I think) is to create a temp file in the destination directory with a throwaway initial name. This approach seems like a good tradeoff to me. I agree that using a temp directory for an arbitrarily-large file that is intended to be written to disk is a big mistake. I don't think any tools I regularly use do this, but my /tmp is a tmpfs so it wouldn't be too pessimal on my setup.
> As a side note: for POSIX OS's, this is why I much prefer the FD based operations. I don't think it quite exists, but I really think the right answer here is to create a deleted file, and then give it a filename. That is, you write the data out to disk, and hardlink it into its final resting place. Atomic, but with no mess of figuring out a temporary name. This is the reverse of how temporary files work, where you create a temp file & then delete it, before writing to it. (Linux allows this; it'll clean up the file when it is closed. It's backed by disk, and since it lacks a name, it can't be inadvertently opened or messed with by other programs. It's a way of saying "give me anonymous disk space".) There's a syscall to create deleted files in one-shot, now, but I don't think there's a way to hardlink them, yet. (Note that you need to still provide either a path, or the FD to a directory, s.t. the OS can determine what FS should back the file, and that you have access to disk at all.)
How would you specify which filesystem the deleted file should be created on?
In addition, something is off with drag-and-drop extraction. AFAIR, you can't make the desktop visible first by dragging to the right edge of the taskbar. Maybe they fixed it, but in the meantime I got used to 7-Zip FM.
Peazip is great. I love that there's a portable version--it has come in handy before when I didn't have installation permissions. At the time (not sure if it's still the case now), WinRAR or 7zip didn't seem to have portable versions listed on their homepages and the other sites proclaiming that there are looked shady.
I tried this program and ended up switching back to 7zip because this program did not work well on a 4k screen (scaling was realllllly bad) and there was a lack of visual feedback for the extraction operation. I felt like I could customize 7z more towards what I needed.
There's info here about their macOS port progress - but with all the discussion on that page about Carbon (!) not being fully implemented in Lazarus, and recommendations to run in Parallels, it seems unlikely.
(Carbon was the API for compatibility with Mac OS 8 & 9 on Mac OS X, and was deprecated in Mountain Lion.)
32 comments
[ 3.3 ms ] story [ 81.4 ms ] thread"Read (browse, extract, test) 7z, Google Android's apk, bz, bz2, bzip2, tbz2, tbz, gz, gzip, tgz, tpz, tar, zip, zipx, z01, smzip, arj, cab, chm, chi, chq, chw, hxs, hxi, hxr, hxq, hxw, lit, cpio, deb, lzh, lha, rar, r01, 00, rpm, z, taz, tz, iso, Java (jar, ear, war), pet, pup, pak, pk3, pk4, slp, [Content], xpi, wim, u3p, lzma86, lzma, udf, xar, Apple's dmg, hfs, part1, split, swm, tpz, kmz, xz, txz, vhd, mslz, apm, mbr, fat, ntfs, exe, dll, sys, msi, msp, Open Office / Libre Office (ods, ots, odm, oth, oxt, odb, odf, odg, otg, odp, otp, odt, ott), gnm, Microsoft Office (doc, dot, xls, xlt, ppt, pps, pot, docx, dotx, xlsx, xltx), Flash (swf, flv), quad, balz, bcm, zpaq, paq8f, paq8jd, paq8l, paq8o, lpaq1, lpaq5, lpaq8, ace through separate unace plugin (closed source) available on PeaZip add-ons page, arc, wrc, 001, pea, cbz, cbr, cba, cb7, cbt (and more...)"
Open Source, Cross Platform, and Free.
Also written in Lazarus/FreePascal...
Project Goals #2:
"Bring focus on Lazarus/FreePascal
I'm developing PeaZip project in FreePascal language, under Lazarus IDE. I like Pascal-related languages and I think Lazarus/FreePascal is one of the best cross-platform IDE available; I like it even more because it is open source and because it's growing day by day in a more mature and powerful IDE. I'll be glad to bring a bit of developer's attention on Lazarus/FreePascal through my project."
Delphi may be dead(*), but Lazarus/FreePascal is very much alive and kicking...
More power to you, oh-as-of-yet-unknown WinZip/WinRar open source replacement-writing author!!! <g>
This was also probably around the time when there was that big public hoo-ha about MS XML formats vs. Open Office / Open Document formats. I had read some about it at the time, don't remember the full details.
I believe they're saying a file archiver should _not_ do this, and that PeaZIP does _not_ do this.
> I haven't looked back.
I believe this means that they're happy with PeaZIP.
As a side note: for POSIX OS's, this is why I much prefer the FD based operations. I don't think it quite exists, but I really think the right answer here is to create a deleted file, and then give it a filename. That is, you write the data out to disk, and hardlink it into its final resting place. Atomic, but with no mess of figuring out a temporary name. This is the reverse of how temporary files work, where you create a temp file & then delete it, before writing to it. (Linux allows this; it'll clean up the file when it is closed. It's backed by disk, and since it lacks a name, it can't be inadvertently opened or messed with by other programs. It's a way of saying "give me anonymous disk space".) There's a syscall to create deleted files in one-shot, now, but I don't think there's a way to hardlink them, yet. (Note that you need to still provide either a path, or the FD to a directory, s.t. the OS can determine what FS should back the file, and that you have access to disk at all.)
The way many programs deal with this (Firefox, rsync by default I think) is to create a temp file in the destination directory with a throwaway initial name. This approach seems like a good tradeoff to me. I agree that using a temp directory for an arbitrarily-large file that is intended to be written to disk is a big mistake. I don't think any tools I regularly use do this, but my /tmp is a tmpfs so it wouldn't be too pessimal on my setup.
> As a side note: for POSIX OS's, this is why I much prefer the FD based operations. I don't think it quite exists, but I really think the right answer here is to create a deleted file, and then give it a filename. That is, you write the data out to disk, and hardlink it into its final resting place. Atomic, but with no mess of figuring out a temporary name. This is the reverse of how temporary files work, where you create a temp file & then delete it, before writing to it. (Linux allows this; it'll clean up the file when it is closed. It's backed by disk, and since it lacks a name, it can't be inadvertently opened or messed with by other programs. It's a way of saying "give me anonymous disk space".) There's a syscall to create deleted files in one-shot, now, but I don't think there's a way to hardlink them, yet. (Note that you need to still provide either a path, or the FD to a directory, s.t. the OS can determine what FS should back the file, and that you have access to disk at all.)
How would you specify which filesystem the deleted file should be created on?
I know PeaZip is based on that, so I wonder what made you choose this over 7z?
It's available via 'cnet downloads'. So... NOPE.
I believe this was posted because user @peter_d_sherman is the 10,000 of the day [2].
[1] https://en.wikipedia.org/wiki/PeaZip
[2] https://xkcd.com/1053/
(Carbon was the API for compatibility with Mac OS 8 & 9 on Mac OS X, and was deprecated in Mountain Lion.)
http://www.peazip.org/mac-osx-rar-zip-utility.html
(EDIT: I originally thought the page had instructions to build yourself on macOS)