On 2/16/23 07:57, db wrote:
This might be the wrong ng but anyway...
I refer to using typed commands in Linux.
With tar, I can use the option -t to get a list of a
tarred file's contents.
I can't however find such an option for zip, so I have
to go into GUI and click on the zip file to see the contents.
Am I missing that option, or isn't there one?
Oh there is one but the option is -h ands you can see the result.
[bliss@box ~]$ zip -h
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
The default action is to add or replace zipfile entries from list, which
can include the special name - to compress standard input.
If zipfile and list are omitted, zip compresses stdin to stdout.
-f freshen: only changed files -u update: only changed or new files
-d delete entries in zipfile -m move into zipfile (delete OS
files)
-r recurse into directories -j junk (don't record) directory
names
-0 store only -l convert LF to CR LF (-ll CR LF
to LF)
-1 compress faster -9 compress better
-q quiet operation -v verbose operation/print
version info
-c add one-line comments -z add zipfile comment
-@ read names from stdin -o make zipfile as old as latest
entry
-x exclude the following names -i include only the following names
-F fix zipfile (-FF try harder) -D do not add directory entries
-A adjust self-extracting exe -J junk zipfile prefix (unzipsfx)
-T test zipfile integrity -X eXclude eXtra file attributes
-y store symbolic links as the link instead of the referenced file
-e encrypt -n don't compress these suffixes
-h2 show more help
The -h option is short for help. No doubt an artifact
of the English language dominance in early computer development.
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
On 2023-02-18 11:12, The Natural Philosopher wrote:
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
Could never find an unpacking program that ran on Unix.
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
On 2023-02-17, Carlos E. R. <robin_listas@es.invalid> wrote:
On 2023-02-17 17:28, Robert Heller wrote:
I recall there being two separate programs, PKZIP.EXE and PKUNZIP.EXE.Zip / Unzip have a bit of a history and came from outside of theEr... that's not my remembrance. I recall a single program, called
UNIX world (they originated in the MS-DOS world). I suspect that due
to MS-DOS memory / disk limitations the *original* programs for Zip
files had to be limited to single functions (just building the zip
file, just extracting, just listing, etc.). Along with a different
philosophy about how to organize software.
"pkzip". Maybe there was an older zip/unzip, but what we used before
pkzip was another format, arc.
In fact, I just dug around on my system and found them both. They're
dated 1993-02-01.
<https://en.wikipedia.org/wiki/PKZIP>Note that the label on the floppy disk in the photo mentions both
PKZIP and PKUNZIP.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
7-zip is better than old-fashioned zip and ALMOST as
portable these days. You can easily get 7-zip for
linux and Winders.
On Sat, 18 Feb 2023 03:59:16 -0500, 25B.R866 wrote:
7-zip is better than old-fashioned zip and ALMOST as
portable these days. You can easily get 7-zip for
linux and Winders.
Possible.
But I notice some people send me a file with a ZIP extension. Often
turns out it's 7-zip, so "unzip" fails. I have 7z installed though and it works. Would be nice though if (un)zip not just fails in these cases, but uses 7z then. Otherwise I have to let 7z do it.
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
On 2023-02-18 14:15, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
:-O
unrar.
Unix, or Linux?
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
On 18/02/2023 16:39, Carlos E.R. wrote:
On 2023-02-18 14:15, The Natural Philosopher wrote:Unix.
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
:-O
unrar.
Unix, or Linux?
I cant remember when Linux first appeared on the desktops - I believe
that Mr Kettlewell was among the first in our company to espouse it, but
it was preceded by a lot of SCO Unix and SUNoS .
Curiously the advent of wide area networking and ultimately the Internet propelled both the RAR format and Linux into popularity. It is hard to
see how co-operative development of Linux would have taken place without
the Internet and the ability to download and upload files globally, and
the need for RAR was IIRC driven by the first 'torrents' of pirated software...
Anyway, for a long time it remained a DOS/WIN only program.
On 2/18/23 4:16 PM, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 03:59:16 -0500, 25B.R866 wrote:
Possible.
7-zip is better than old-fashioned zip and ALMOST as
portable these days. You can easily get 7-zip for
linux and Winders.
But I notice some people send me a file with a ZIP extension. Often
turns out it's 7-zip, so "unzip" fails. I have 7z installed though and it
works. Would be nice though if (un)zip not just fails in these cases, but
uses 7z then. Otherwise I have to let 7z do it.
PROPERLY, you use the ".7z" extension when making
zips with p7. Not everybody does that however.
My idea was that if unzip discovers a file you try to deflate is not in
ZIP format that it would automatically look into the file and for example finds out it's 7Z. Then calls 7z, or if not installed recommends it and aborts.
Andreas Kohlbach <ank@spamfence.net> wrote:
My idea was that if unzip discovers a file you try to deflate is not in
ZIP format that it would automatically look into the file and for example
finds out it's 7Z. Then calls 7z, or if not installed recommends it and
aborts.
I suggest writing a script that looks at the output of the 'file'
command and picks the program based on that.
On 2023-02-19 12:10, The Natural Philosopher wrote:
On 18/02/2023 16:39, Carlos E.R. wrote:
On 2023-02-18 14:15, The Natural Philosopher wrote:Unix.
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving
formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
:-O
unrar.
Unix, or Linux?
I cant remember when Linux first appeared on the desktops - I believe
that Mr Kettlewell was among the first in our company to espouse it,
but it was preceded by a lot of SCO Unix and SUNoS .
I suppose that unrar can be compiled in Unix, the source is available.
unrar for unix is mentioned here, for instance:
<https://www.cyberciti.biz/faq/open-rar-file-or-extract-rar-files-under-linux-or-unix/>
+++··················
If you are using FreeBSD Unix, use the pkg command:
# pkg install unrar
If you are using OpenBSD Unix, use the pkg_add command:
# pkg_add -v unrar
If you are using macOS Unix and Homebrew, use the brew command. First, install Homebrew on macOS and then type the following brew command:
$ brew install unrar
··················++-
Curiously the advent of wide area networking and ultimately the
Internet propelled both the RAR format and Linux into popularity. It
is hard to see how co-operative development of Linux would have taken
place without the Internet and the ability to download and upload
files globally, and the need for RAR was IIRC driven by the first
'torrents' of pirated software...
Anyway, for a long time it remained a DOS/WIN only program.
Certainly Linux development came with Internet. That is known history.
RAR was very popular in the DOS world, but it started in 1993, so the
same era as Linux.
https://en.wikipedia.org/wiki/RAR_(file_format)
«RAR is a proprietary archive file format that supports data
compression, error correction and file spanning.[3] It was developed in
1993 by Russian software engineer Eugene Roshal and the software is
licensed by win.rar GmbH.[3] The name RAR stands for Roshal Archive.»
RAR had good features before internet. It could easily create archives spanning several floppies, it had forward error recovery... It had some
sort of support for script running with decompress, useful for
installation of programs.
On 2/19/23 6:42 AM, Carlos E.R. wrote:
On 2023-02-19 12:10, The Natural Philosopher wrote:
On 18/02/2023 16:39, Carlos E.R. wrote:
On 2023-02-18 14:15, The Natural Philosopher wrote:Unix.
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
On 17/02/2023 19:32, Charlie Gibbs wrote:
I was becoming so tired of the proliferation of file archiving >>>>>>>> formats (ARC, ZOO, ARJ, etc.) that I was relieved to see the
world finally settle on ZIP as a standard archiving format.
(Uh-oh, here comes 7Zip...)
And this is all separate from the Unix world, which had
tar, cpio, gzip...
RAR was my pet hate...
Why? :-? :-o
:-O
unrar.
Unix, or Linux?
I cant remember when Linux first appeared on the desktops - I believe
that Mr Kettlewell was among the first in our company to espouse it,
but it was preceded by a lot of SCO Unix and SUNoS .
I suppose that unrar can be compiled in Unix, the source is available.
unrar for unix is mentioned here, for instance:
<https://www.cyberciti.biz/faq/open-rar-file-or-extract-rar-files-under-linux-or-unix/>
+++··················
If you are using FreeBSD Unix, use the pkg command:
# pkg install unrar
If you are using OpenBSD Unix, use the pkg_add command:
# pkg_add -v unrar
If you are using macOS Unix and Homebrew, use the brew command. First,
install Homebrew on macOS and then type the following brew command:
$ brew install unrar
··················++-
Curiously the advent of wide area networking and ultimately the
Internet propelled both the RAR format and Linux into popularity. It
is hard to see how co-operative development of Linux would have taken
place without the Internet and the ability to download and upload
files globally, and the need for RAR was IIRC driven by the first
'torrents' of pirated software...
Anyway, for a long time it remained a DOS/WIN only program.
Certainly Linux development came with Internet. That is known history.
RAR was very popular in the DOS world, but it started in 1993, so the
same era as Linux.
https://en.wikipedia.org/wiki/RAR_(file_format)
«RAR is a proprietary archive file format that supports data
compression, error correction and file spanning.[3] It was developed
in 1993 by Russian software engineer Eugene Roshal and the software is
licensed by win.rar GmbH.[3] The name RAR stands for Roshal Archive.»
RAR had good features before internet. It could easily create archives
spanning several floppies, it had forward error recovery... It had
some sort of support for script running with decompress, useful for
installation of programs.
Well, even plain old zip could make floppy-spanning
archives WAY back.
THESE days I'd rec 7zip. Does pretty much anything
you'd ever need and it's snappier than RAR or zip
and compresses a bit better.
Alas a legacy of the past is that there were maybe
50 unique compression/archive schemes - some totally
proprietary like "Squeeze!". Finding unzippers for
all those schemes is a hopeless task - so, hate to
say it, some of that old data just has to be let go.
On 2/19/23 6:42 AM, Carlos E.R. wrote:
On 2023-02-19 12:10, The Natural Philosopher wrote:
Certainly Linux development came with Internet. That is known
history.
RAR was very popular in the DOS world, but it started in 1993, so
the same era as Linux.
https://en.wikipedia.org/wiki/RAR_(file_format)
RAR is a proprietary archive file format that supports data
compression, error correction and file spanning.[3] It was developed
in 1993 by Russian software engineer Eugene Roshal and the software
is licensed by win.rar GmbH.[3] The name RAR stands for Roshal
Archive.
RAR had good features before internet. It could easily create
archives spanning several floppies, it had forward error
recovery... It had some sort of support for script running with
decompress, useful for installation of programs.
Well, even plain old zip could make floppy-spanning
archives WAY back.
THESE days I'd rec 7zip. Does pretty much anything
you'd ever need and it's snappier than RAR or zip
and compresses a bit better.
On Wed, 22 Feb 2023 00:58:58 -0500, 25B.E866 wrote:
THESE days I'd rec 7zip. Does pretty much anything
you'd ever need and it's snappier than RAR or zip
and compresses a bit better.
Still I say ZIP is a common noun. Many people refer to "zip" when ever something comes compressed in an archive. Therefor the program unzip
should not abort if it finds something else than a zip compressed
archive. Instead find out what it is (Linux' command "file" can do that)
and delegate the job to the appropriate program (like 7z).
Yes, there was suggested to write a wrapper. But in my opinion that
should be included into the program unzip, as ZIP still a common noun.
Andreas Kohlbach <ank@spamfence.net> wrote:
On Wed, 22 Feb 2023 00:58:58 -0500, 25B.E866 wrote:
THESE days I'd rec 7zip. Does pretty much anything
you'd ever need and it's snappier than RAR or zip
and compresses a bit better.
Still I say ZIP is a common noun. Many people refer to "zip" when ever
something comes compressed in an archive. Therefor the program unzip
should not abort if it finds something else than a zip compressed
archive. Instead find out what it is (Linux' command "file" can do that)
and delegate the job to the appropriate program (like 7z).
Yes, there was suggested to write a wrapper. But in my opinion that
should be included into the program unzip, as ZIP still a common noun.
Not in my world it isn't, it sounds like you just know some very
confused people. But what's with the obsession for changing unzip
when you could just switch to using 7-Zip for all the various
"zips" by default instead?
From the 7z man page:
"7-Zip is a file archiver supporting 7z (that implements LZMA
compression algorithm featuring very high compression ratio),
LZMA2, XZ, ZIP, Zip64, CAB, RAR (if the non-free p7zip-rar package
is installed), ARJ, GZIP, BZIP2, TAR, CPIO, RPM, ISO, most
filesystem images and DEB formats."
On 23 Feb 2023 09:23:37 +1000, Computer Nerd Kev wrote:
Andreas Kohlbach <ank@spamfence.net> wrote:
On Wed, 22 Feb 2023 00:58:58 -0500, 25B.E866 wrote:
THESE days I'd rec 7zip. Does pretty much anything
you'd ever need and it's snappier than RAR or zip
and compresses a bit better.
Still I say ZIP is a common noun. Many people refer to "zip" when ever
something comes compressed in an archive. Therefor the program unzip
should not abort if it finds something else than a zip compressed
archive. Instead find out what it is (Linux' command "file" can do that) >>> and delegate the job to the appropriate program (like 7z).
Yes, there was suggested to write a wrapper. But in my opinion that
should be included into the program unzip, as ZIP still a common noun.
Not in my world it isn't, it sounds like you just know some very
confused people. But what's with the obsession for changing unzip
when you could just switch to using 7-Zip for all the various
"zips" by default instead?
From the 7z man page:
"7-Zip is a file archiver supporting 7z (that implements LZMA
compression algorithm featuring very high compression ratio),
LZMA2, XZ, ZIP, Zip64, CAB, RAR (if the non-free p7zip-rar package
is installed), ARJ, GZIP, BZIP2, TAR, CPIO, RPM, ISO, most
filesystem images and DEB formats."
That I didn't know. That removes my concerns. Thanks. :-)
It even handles ARJ as I see from that excerpt. *g*
7-zip is *very* versatile - WORTH using. A good
step up from age-old Zip (but you CAN do those
age-old Zips with it too).
It's SUPPOSED to come with a dedicated GUI too, but
for some reason it doesn't seem to be included in
the Deb repos - or at least I can't find/run it.
25B.E866 wrote:
7-zip is *very* versatile - WORTH using. A good
step up from age-old Zip (but you CAN do those
age-old Zips with it too).
It's SUPPOSED to come with a dedicated GUI too, but
for some reason it doesn't seem to be included in
the Deb repos - or at least I can't find/run it.
Details of package p7zip-full in bullseye https://packages.debian.org/en/bullseye/p7zip-full
How to Install 7-Zip on Debian 11 or 10 - LinuxCapable https://www.linuxcapable.com/how-to-install-7-zip-on-debian-linux/
On 2/23/23 5:32 AM, Andrei Z. wrote:
25B.E866 wrote:
7-zip is *very* versatile - WORTH using. A good
step up from age-old Zip (but you CAN do those
age-old Zips with it too).
It's SUPPOSED to come with a dedicated GUI too, but
for some reason it doesn't seem to be included in
the Deb repos - or at least I can't find/run it.
Details of package p7zip-full in bullseye
https://packages.debian.org/en/bullseye/p7zip-full
How to Install 7-Zip on Debian 11 or 10 - LinuxCapable
https://www.linuxcapable.com/how-to-install-7-zip-on-debian-linux/
Been there, no luck. Weird.
Maybe I'll be inspired to write my own
front end :-)
25B.E866 wrote:
On 2/23/23 5:32 AM, Andrei Z. wrote:
25B.E866 wrote:
7-zip is *very* versatile - WORTH using. A good
step up from age-old Zip (but you CAN do those
age-old Zips with it too).
It's SUPPOSED to come with a dedicated GUI too, but
for some reason it doesn't seem to be included in
the Deb repos - or at least I can't find/run it.
Details of package p7zip-full in bullseye
https://packages.debian.org/en/bullseye/p7zip-full
How to Install 7-Zip on Debian 11 or 10 - LinuxCapable
https://www.linuxcapable.com/how-to-install-7-zip-on-debian-linux/
Been there, no luck. Weird.
Maybe I'll be inspired to write my own
front end :-)
"p7zip-full provides utilities to pack and unpack 7z archives within a
shell or using a GUI (such as Ark, File Roller or Nautilus)."
Details of package file-roller in bullseye https://packages.debian.org/en/bullseye/file-roller
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
Next weeks project ....
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
25B.E866 <25B.E866@noaaba.net> wrote:
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
Only on Linux.
I quite like the Windows GUI for 7-Zip, it can be
set up in a commander-style layout and almost works as a general
purpose file manager. I use 7-Zip in Windows much more than in
Linux, because it opens tar.* files. In Linux the files I deal with
are almost always ZIP, GZIP, BZIP2, or XZ, and the standard tools
do fine for them, as well as the decompression support built into
GUI file managers (which is sometimes user-customisable for adding
missing formats like 7Zip as well).
7-Zip for Windows will run in WINE: https://appdb.winehq.org/objectManager.php?sClass=version&iId=40417
25B.E866 wrote:
Next weeks project ....p7zip looks abandoned.
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
https://sourceforge.net/projects/p7zip/
7-Zip for Linux first release 2021-03-10 https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia article
doesn't have dates for these. But as soon as those sources appeared,
anybody could compile a version for Unix.
On 2/23/23 11:58 PM, Andrei Z. wrote:
25B.E866 wrote:
Next weeks project ....p7zip looks abandoned.
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
https://sourceforge.net/projects/p7zip/
7-Zip for Linux first release 2021-03-10
https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
"Abandoned" - or just "perfected" ???
Once you Get It Right .....
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
25A.I866 wrote:
On 2/23/23 11:58 PM, Andrei Z. wrote:
25B.E866 wrote:
Next weeks project ....p7zip looks abandoned.
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
https://sourceforge.net/projects/p7zip/
7-Zip for Linux first release 2021-03-10
https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
"Abandoned" - or just "perfected" ???
Once you Get It Right .....
p7zip
https://github.com/btolab/p7zip
"7z archiver with source history"
"A new p7zip fork with additional codecs and improvements" https://github.com/jinfeihan57/p7zip/
25A.I866 <25A.I866@noacba.net> wrote:
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
A degaussing coil is the usual method to do this, and does not
involve disassembly nor writing Pascal or C code.
And, for your 'flakey' drives, trying to overwrite by using the drive
itself may not work at all. While the degaussing coil just scrambles
the magnetic domains on the platters.
Search for one meant for erasing disks, ones meant for mag-tape may not
be powerful enough for the magnetic material used in disks.
25A.I866 <25A.I866@noacba.net> wrote:
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
A degaussing coil is the usual method to do this, and does not
involve disassembly nor writing Pascal or C code.
And, for your 'flakey' drives, trying to overwrite by using the drive
itself may not work at all. While the degaussing coil just scrambles
the magnetic domains on the platters.
Search for one meant for erasing disks, ones meant for mag-tape may not
be powerful enough for the magnetic material used in disks.
On 2/23/23 11:58 PM, Andrei Z. wrote:
25B.E866 wrote:
Next weeks project ....p7zip looks abandoned.
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
https://sourceforge.net/projects/p7zip/
7-Zip for Linux first release 2021-03-10
https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
"Abandoned" - or just "perfected" ???
Once you Get It Right .....
On 2/25/23 1:34 AM, Andrei Z. wrote:
"A new p7zip fork with additional codecs and improvements"
https://github.com/jinfeihan57/p7zip/
Sounds good.
But why do people keep re-inventing the wheel ???
On 2/25/23 1:34 AM, Andrei Z. wrote:
25A.I866 wrote:
On 2/23/23 11:58 PM, Andrei Z. wrote:
25B.E866 wrote:
Next weeks project ....p7zip looks abandoned.
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
https://sourceforge.net/projects/p7zip/
7-Zip for Linux first release 2021-03-10
https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
"Abandoned" - or just "perfected" ???
Once you Get It Right .....
p7zip
https://github.com/btolab/p7zip
"7z archiver with source history"
"A new p7zip fork with additional codecs and improvements"
https://github.com/jinfeihan57/p7zip/
Sounds good.
But why do people keep re-inventing the wheel ???
There's VERY little improvement in 'zipping' in
terms of speed/compression/ease in the last 20
years. Basically, what you get is not "improved",
just "different".
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia article
doesn't have dates for these. But as soon as those sources appeared,
anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived
from the ASCII values of the digits minus-48). It MAY be a bit
faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using
'dd' to zero (or pattern-write) a whole drive but because it's
not as complex it's about 30% quicker. Added a 'skitter' option
that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
On 2/25/23 1:15 AM, Rich wrote:
25A.I866 <25A.I866@noacba.net> wrote:
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
A degaussing coil is the usual method to do this, and does not
involve disassembly nor writing Pascal or C code.
I don't have one big enough to affect modern HDD platters.
But the cold-chisel method .........
And, for your 'flakey' drives, trying to overwrite by using the drive
itself may not work at all. While the degaussing coil just scrambles
the magnetic domains on the platters.
Search for one meant for erasing disks, ones meant for mag-tape may not
be powerful enough for the magnetic material used in disks.
The only one I have was meant for floppies.
But a little Bang Bang with the silver hammer :-)
It is BEST to disassemble. It's almost a sin to waste
those rare-earth magnets and the platters are SO
attractive. But, if there's just no time .....
However, regardless of the final method, some kind of
software wipe beforehand IS wise.
I don't think old HDDs are AS likely to be found/exploited
as some alarmists would like us to believe. However there
is still "good practice" ... you need to be able to SAY
you put in The Effort to prevent piracy.
Strictly, from the electronic angle, a hand "Stun Gun"
at 50000-100000 volts played across the contacts in
the back will make a BIG mess of things. Someone would
literally have to physically remove the platters and
insert them in the same model of drive or own custom
hardware that'll scan/decode any platter ($$$$$$!!!).
Now CDs/DVDs ... just put 'em in the microwave and set it
for five seconds. The results are VERY artistic. Lotsa
sparks. OR, just snap 'em in half (not as fun).
On 25/02/2023 07:33, 25A.I866 wrote:
On 2/25/23 1:34 AM, Andrei Z. wrote:
Marketing. This is not just *any* wheel, this is a wheel whose extra roundness, and superlative styling makes your existing wheel - well -Sounds good.
"A new p7zip fork with additional codecs and improvements"
https://github.com/jinfeihan57/p7zip/
But why do people keep re-inventing the wheel ???
simply *passé*, darlings
On 2/23/23 10:18 PM, Computer Nerd Kev wrote:
25B.E866 <25B.E866@noaaba.net> wrote:
I had gotten the impression that the 7zip people
had written their very own GUI front end, but it
looks like they rely on others.
Only on Linux.
How discriminatory !!!
On 25/02/2023 07:30, 25A.I866 wrote:
On 2/25/23 1:15 AM, Rich wrote:+1
25A.I866 <25A.I866@noacba.net> wrote:
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
A degaussing coil is the usual method to do this, and does not
involve disassembly nor writing Pascal or C code.
I don't have one big enough to affect modern HDD platters.
But the cold-chisel method .........
And, for your 'flakey' drives, trying to overwrite by using the drive
itself may not work at all. While the degaussing coil just scrambles
the magnetic domains on the platters.
Search for one meant for erasing disks, ones meant for mag-tape may not
be powerful enough for the magnetic material used in disks.
The only one I have was meant for floppies.
But a little Bang Bang with the silver hammer :-)
It is BEST to disassemble. It's almost a sin to wasteReally? We all did in *one* time, to see what was inside.
those rare-earth magnets and the platters are SO
attractive. But, if there's just no time .....
Rare earth magnets are ten a penny.
However, regardless of the final method, some kind ofIf you say so. I mean really who honestly cares?
software wipe beforehand IS wise.
I don't think old HDDs are AS likely to be found/exploitedThat's just hand wavy nonsense. The sort of person who can take - particularly a Linux hard drive - even in perfect working order and reconstruct an erased file, is unlikely to be so short of money that he prowls junk yards looking for drives that might have something on them,
as some alarmists would like us to believe. However there
is still "good practice" ... you need to be able to SAY
you put in The Effort to prevent piracy.
and the people that did are looking for someone who left a full windows install in there with all their bank passwords encoded into IE6, that is accessible by a script within 30 seconds. If it isn't recognised because
its ext2/3/4 they will toss the drive anyway. Or reformat it and sell it
on ebay
Strictly, from the electronic angle, a hand "Stun Gun"ER no, what WE did, was to take an identical drive with drive errors,
at 50000-100000 volts played across the contacts in
the back will make a BIG mess of things. Someone would
literally have to physically remove the platters and
insert them in the same model of drive or own custom
hardware that'll scan/decode any platter ($$$$$$!!!).
remove its whole circuit board and replace the buggered one on OUR
drive, long enough to get the data off. It is actually reasonably simple
- or was at that time.
Now CDs/DVDs ... just put 'em in the microwave and set it
for five seconds. The results are VERY artistic. Lotsa
sparks. OR, just snap 'em in half (not as fun).
...
Now CDs/DVDs ... just put 'em in the microwave and set it
for five seconds. The results are VERY artistic. Lotsa
sparks. OR, just snap 'em in half (not as fun).
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia article
doesn't have dates for these. But as soon as those sources appeared,
anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived
from the ASCII values of the digits minus-48). It MAY be a bit
faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using
'dd' to zero (or pattern-write) a whole drive but because it's
not as complex it's about 30% quicker. Added a 'skitter' option
that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly random
data, and does so at the SATA speed of the (mechanical) disk, about 190
MB/S last time I tried. I have done 4 TB disks.
On 25/02/2023 06:15, Rich wrote:
25A.I866 <25A.I866@noacba.net> wrote:Actually it isn't.
FYI - I have a PILE of old HDDs ... some just Too Old, others
Flakey. They NEED to be wiped, or at least quasi-wiped, before
disposal.
A degaussing coil is the usual method to do this, and does not
involve disassembly nor writing Pascal or C code.
In commercial cleanups of old machine rooms data centres and offices,
the usual method is a crusher. My ex BIL in charge of IT rollouts to
replace obsolescent kit in huge companies used to be able to get cheap machines from the recyclers, but never hard drives
Amateurs may use a sledge hammer.
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote: >>>>>>>
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia
article doesn't have dates for these. But as soon as those sources
appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived
from the ASCII values of the digits minus-48). It MAY be a bit
faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using
'dd' to zero (or pattern-write) a whole drive but because it's
not as complex it's about 30% quicker. Added a 'skitter' option
that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly random
data, and does so at the SATA speed of the (mechanical) disk, about
190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Had to make a 'C' "helper" because, with some flags
and such, you CAN lseek64(). If you just wanna melt
a disk then FPC is ok, but if you wanna SEE/search for
what's ON the disk at the 3.345tb mark then you have
to cheat.
My experimental disk was an old UServer drive. There
WERE some recognizable passwords and such WAY out
in the diskspace (maybe the swap partition ?)
As I discussed with Mr. Natural, wiping an old disk
is considered "good practice". However literally
writing zeros or whatever over a whole 4/8/12tb
disk can involve DAYS. Physical destruction is
quicker. You can disassemble and save the magnets
and pretty platters OR use a cold-chisel ....
(WD drives. just off center at about the 8 o-clock
position) ...
A *fairly* easy approach is to use gparted ... create
a new partition table and then reformat EXT2. Now it's
faster to reformat EXT3/4 but EXT2 does a LOT more
work redoing of the disk to it's own special, and now
rarely-used, way. No hope for the casual hacks after that ...
SSDs, physically destroy - the wear-leveling scheme
thwarts the usual overwrite methods.
CD/DVD - five secs in an old microwave. Very artistic
results too.
On 2023-02-26 05:41, 25A.I866 wrote:
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote: >>>>>>>>
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia
article doesn't have dates for these. But as soon as those sources
appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived
from the ASCII values of the digits minus-48). It MAY be a bit
faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using
'dd' to zero (or pattern-write) a whole drive but because it's
not as complex it's about 30% quicker. Added a 'skitter' option
that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly random
data, and does so at the SATA speed of the (mechanical) disk, about
190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Yes, you said so, but I have not noticed this. I may do the experiment
the next time I get an empty hard disk and free time.
I use this call:
repeat
...
{$I-}write(Fout,BigData[RandomIndex]);{$I+}
gotresult:= ioresult;
until gotresult <> 0;
Each write writes a 1 GiB array of bytes, stored in RAM.
where:
const
shuflecount = 1024;
arraysize = 1023;
ChunkSz=1048576;
type
tCacho= array [1..ChunkSz] of byte;
var
RandomIndex, RandomizeIndex: integer;
BigData : array [1..shuflecount] of tCacho;
Fin, Fout: file of tCacho;
My notes say do not use blockread.BlockRead
An experiment would be to write each sector with its LBA number, then
use dd to verify.
On 2/26/23 2:22 PM, Carlos E.R. wrote:
On 2023-02-26 05:41, 25A.I866 wrote:
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote: >>>>>>>>>
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2
sources were published when version 3 appeared. The wikipedia
article doesn't have dates for these. But as soon as those sources >>>>>> appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived
from the ASCII values of the digits minus-48). It MAY be a bit
faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using
'dd' to zero (or pattern-write) a whole drive but because it's
not as complex it's about 30% quicker. Added a 'skitter' option >>>>> that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly
random data, and does so at the SATA speed of the (mechanical) disk,
about 190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Yes, you said so, but I have not noticed this. I may do the experiment
the next time I get an empty hard disk and free time.
Please do.
There MAY be some compiler directive in FPC, as in GCC, that
smooths out this problem. If so I'd like to know, but a lot
of searching didn't reveal anything.
Anyway, I spent the past week messing around with the seek()
problem in FPC and had to give up and run the external 'C'
helper pgm instead.
On 2023-02-27 05:56, 28A.I873 wrote:
On 2/26/23 2:22 PM, Carlos E.R. wrote:
On 2023-02-26 05:41, 25A.I866 wrote:
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher wrote: >>>>>>>>>>
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version 2 >>>>>>> sources were published when version 3 appeared. The wikipedia
article doesn't have dates for these. But as soon as those
sources appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64()
today. Basically it does powers of ten on each digit (derived >>>>>> from the ASCII values of the digits minus-48). It MAY be a bit >>>>>> faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out
pretty well) but Int64 numbers/functions ARE involved. Today
I took that to write a 'C' "Disk Blaster" ... kinda like using >>>>>> 'dd' to zero (or pattern-write) a whole drive but because it's >>>>>> not as complex it's about 30% quicker. Added a 'skitter' option >>>>>> that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern
block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly
random data, and does so at the SATA speed of the (mechanical)
disk, about 190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Yes, you said so, but I have not noticed this. I may do the
experiment the next time I get an empty hard disk and free time.
Please do.
There MAY be some compiler directive in FPC, as in GCC, that
smooths out this problem. If so I'd like to know, but a lot
of searching didn't reveal anything.
Anyway, I spent the past week messing around with the seek()
problem in FPC and had to give up and run the external 'C'
helper pgm instead.
It will not be before August that I get the time to play with a little project with a self made file server, and I use encrypted disks. I will
need buying the hardware first.
You may remind me of this in August or September ;-)
I will keep worrying about it - I'd *like* FPC to handle
the entire process but damned if their seek() doesn't look
like native 32-bit instead of 64.
On 2/27/23 1:26 PM, Carlos E.R. wrote:
On 2023-02-27 05:56, 28A.I873 wrote:
On 2/26/23 2:22 PM, Carlos E.R. wrote:
On 2023-02-26 05:41, 25A.I866 wrote:
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher >>>>>>>>>> wrote:
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote:Could never find an unpacking program that ran on Unix.
Why? :-? :-o
RAR was my pet hate...
unrar x file.rar
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version >>>>>>>> 2 sources were published when version 3 appeared. The wikipedia >>>>>>>> article doesn't have dates for these. But as soon as those
sources appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64() >>>>>>> today. Basically it does powers of ten on each digit (derived >>>>>>> from the ASCII values of the digits minus-48). It MAY be a bit >>>>>>> faster than the one I wrote the other day for Pascal that
involves 'shrinking down' the presented number. I'll have
to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out >>>>>>> pretty well) but Int64 numbers/functions ARE involved. Today >>>>>>> I took that to write a 'C' "Disk Blaster" ... kinda like using >>>>>>> 'dd' to zero (or pattern-write) a whole drive but because it's >>>>>>> not as complex it's about 30% quicker. Added a 'skitter' option >>>>>>> that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern >>>>>>> block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about
five minutes with 'skittering'. So, you totally obliterate
the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly
random data, and does so at the SATA speed of the (mechanical)
disk, about 190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Yes, you said so, but I have not noticed this. I may do the
experiment the next time I get an empty hard disk and free time.
Please do.
There MAY be some compiler directive in FPC, as in GCC, that
smooths out this problem. If so I'd like to know, but a lot
of searching didn't reveal anything.
Anyway, I spent the past week messing around with the seek()
problem in FPC and had to give up and run the external 'C'
helper pgm instead.
It will not be before August that I get the time to play with a little
project with a self made file server, and I use encrypted disks. I
will need buying the hardware first.
You may remind me of this in August or September ;-)
I will keep worrying about it - I'd *like* FPC to handle
the entire process but damned if their seek() doesn't look
like native 32-bit instead of 64. As said somewhere, when
seeking through, the same stuff (ClamAV virus defs) would
start coming up again right around the 2gb mark, and
4gb mark and ....
Of course my app sounds rather different than yours - I'm
writing a "disk utility" rather than a file server. At least
files on file servers RARELY exceed the magic 32-bit length.
The only things that get THAT bad QUICK are security-cam
videos.
On 2023-02-28 04:20, 28A.I873 wrote:
On 2/27/23 1:26 PM, Carlos E.R. wrote:
On 2023-02-27 05:56, 28A.I873 wrote:
On 2/26/23 2:22 PM, Carlos E.R. wrote:
On 2023-02-26 05:41, 25A.I866 wrote:
On 2/25/23 6:10 AM, Carlos E.R. wrote:
On 2023-02-25 06:51, 25A.I866 wrote:
On 2/19/23 6:48 AM, Carlos E.R. wrote:
On 2023-02-19 12:13, The Natural Philosopher wrote:
On 18/02/2023 21:18, Andreas Kohlbach wrote:
On Sat, 18 Feb 2023 13:15:31 +0000, The Natural Philosopher >>>>>>>>>>> wrote:
unrar x file.rar
On 18/02/2023 11:43, Carlos E.R. wrote:
On 2023-02-18 11:12, The Natural Philosopher wrote: >>>>>>>>>>>>>>Could never find an unpacking program that ran on Unix. >>>>>>>>>>>
RAR was my pet hate...Why? :-? :-o
should deflate the content into the PWD.
Today yes, not in 1993, to run on SCO Unix.
Well, RAR for DOS appeared on 1993! :-D
So in 1993 there wasn't a version for Linux, either.
I believe the sources were published with version 2, or version >>>>>>>>> 2 sources were published when version 3 appeared. The wikipedia >>>>>>>>> article doesn't have dates for these. But as soon as those
sources appeared, anybody could compile a version for Unix.
Always SOUNDS so simple :-)
I always wind up having to write fill-ins for the
missing/very-different library routines between
Win and Lin.
Anyway, I'm not sure about the fascination with RAR.
It is good, but then so are many others that are more
modern/portable/supported.
Found an interesting "loop-based" approach to an Str2Int64() >>>>>>>> today. Basically it does powers of ten on each digit (derived >>>>>>>> from the ASCII values of the digits minus-48). It MAY be a bit >>>>>>>> faster than the one I wrote the other day for Pascal that >>>>>>>> involves 'shrinking down' the presented number. I'll have >>>>>>>> to benchmark. Mine only used integer subtraction and ONE
modulo. Not AS many steps. But, we'll see.
I was writing a "disk visualizer" the other day (turned out >>>>>>>> pretty well) but Int64 numbers/functions ARE involved. Today >>>>>>>> I took that to write a 'C' "Disk Blaster" ... kinda like using >>>>>>>> 'dd' to zero (or pattern-write) a whole drive but because it's >>>>>>>> not as complex it's about 30% quicker. Added a 'skitter' option >>>>>>>> that's applied AFTER the prescribed number of bytes are
overwritten ... 'skittering' means writing yer zero/pattern >>>>>>>> block roughly (a little randomness added to annoy) every
50mb on the REST of the disk area. It is not 'erasure'
per-se, but kinda 'corrupts' and is 50x as fast. You can
go thru a 1tb disk in an external USB3.0 fixture in about >>>>>>>> five minutes with 'skittering'. So, you totally obliterate >>>>>>>> the X-bytes you're most paranoid about and then randomly
insert junk in the rest.
Just gotta smooth-out the params ... there's no slack
right now. Something like 'dd' params would be good.
It always uses the equiv of "bs=1M" ... seems the best
compromise after some experimentation. My visualizer
made it easy to see if the blaster util was doing it
right.
I wrote a tool in pascal to write an entire device with nearly
random data, and does so at the SATA speed of the (mechanical)
disk, about 190 MB/S last time I tried. I have done 4 TB disks.
Free Pascal (I love Pascal) can indeed write an entire
terabyte disk full of zeros or whatever. However what
I discovered is that their "seek" function - despite
docs to the contrary - seems to be only longint. So,
you can't seek beyond 2.4gb, the counter just wraps
into negative numbers. Even tried the 'relative' offset
approach ... no good and a lot more counters to keep
track of.
Yes, you said so, but I have not noticed this. I may do the
experiment the next time I get an empty hard disk and free time.
Please do.
There MAY be some compiler directive in FPC, as in GCC, that
smooths out this problem. If so I'd like to know, but a lot
of searching didn't reveal anything.
Anyway, I spent the past week messing around with the seek()
problem in FPC and had to give up and run the external 'C'
helper pgm instead.
It will not be before August that I get the time to play with a
little project with a self made file server, and I use encrypted
disks. I will need buying the hardware first.
You may remind me of this in August or September ;-)
I will keep worrying about it - I'd *like* FPC to handle
the entire process but damned if their seek() doesn't look
like native 32-bit instead of 64. As said somewhere, when
seeking through, the same stuff (ClamAV virus defs) would
start coming up again right around the 2gb mark, and
4gb mark and ....
Of course my app sounds rather different than yours - I'm
writing a "disk utility" rather than a file server. At least
files on file servers RARELY exceed the magic 32-bit length.
The only things that get THAT bad QUICK are security-cam
videos.
Oh, no, I'm not writing a file server. I just initialize the big disk
(raw) with almost random data, using a program from me.
And the next
time I play with it, hopefully next august, I will try to experiment if
I truly can access it any place, 2GB, 2 TB, etc.
Once the disk is randomized, I just encrypt it with LUKS, and format it
as compressed btrfs. Then I implement a file server with a mini PC and
those disks.
:-D
Kind of self made NAS.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 57:52:31 |
| Calls: | 6,690 |
| Files: | 12,225 |
| Messages: | 5,345,229 |