Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Carlos E.R." Newsgroups: comp.os.linux.misc Subject: Re: Zip list Date: Sun, 26 Feb 2023 20:22:48 +0100 Lines: 165 Message-ID: <85oscjxves.ln2@Telcontar.valinor> References: <0LqcnRugEt7aNnL-nZ2dnZfqnPGdnZ2d@giganews.com> <87pma61xl0.fsf@usenet.ankman.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net ZRwowkliRDd5fIuz4Jc9wAqtd5ojVoUObIaU1TV/mvk1Hwa1vT X-Orig-Path: Telcontar.valinor!not-for-mail Cancel-Lock: sha1:9BdK0QaIDM529eYsDJ5kb987ZAE= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: es-ES, en-CA In-Reply-To: Xref: csiph.com comp.os.linux.misc:37284 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: >>>>>>>>> >>>>>>>>> RAR was my pet hate... >>>>>>>>> >>>>>>>> Why? :-?  :-o >>>>>>>> >>>>>>> Could never find an unpacking program that ran on Unix. >>>>>> >>>>>> 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. > >   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. -- Cheers, Carlos.