Re: Zip list

Subject	Re: Zip list
Newsgroups	comp.os.linux.misc
References	(15 earlier) <85oscjxves.ln2@Telcontar.valinor> <krWcnaVOHetrqmH-nZ2dnZfqnPudnZ2d@earthlink.com> <m79vcjxg3n.ln2@Telcontar.valinor> <VqOcnTYIGLWH7mD-nZ2dnZfqn_qdnZ2d@earthlink.com> <ssv4djxjc7.ln2@Telcontar.valinor>
From	"28A.I873" <28A.I873@noabzba.net>
Organization	mitotic resell
Date	2023-03-02 00:02 -0500
Message-ID	<cw-dnSawAdyRs535nZ2dnZfqn_WdnZ2d@earthlink.com> (permalink)

Show all headers | View raw

On 3/1/23 5:23 PM, Carlos E.R. wrote:
> 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:
>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>
>>>>    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. 

   'Zactly what I just wrote. If you keep it kinda simple
   and write it in 'C' it can be notably faster than 'dd'.

   Assuming by 'initialize' you mean "overwriting everything
   important that WAS there ...".

   My parallel app is a disk "visualizer". That's in Laz/FPC.
   That's where the seek issue really came to light. However
   the 'C' fix also encouraged me to write a "disk destroyer"
   concurrently since I have so MANY old disks around (like
   a 3' stack at this point) that really ought to go to
   public auction. Need to add a "zap from the bottom" option
   though to nuke where swap parts often go.

> 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.

   There MAY be an update/upgrade by then. The DOCS say their
   seek is int64 - but, for the fairly recent versions, it
   just AIN'T.

   Oh, note that the Bullseye archives for Laz/FPC are
   DEFECTIVE. There's an illegal mix of versions. You
   have to go to the actual site and download the three
   main debs, then install in the correct order. THEN
   it works.

> 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.

   I've kinda stayed away from encryption - though it DOES have
   its place. In my particular situation no disk is ever gonna
   leave the premises without me knowing about it. My concern
   about encryption is that, and the prob varies per method, even
   a single bit/byte error can trash the entire decryption process.
   Encryption where what follows is tightly based to what just was ...
   there's the most vulnerable scene.

> :-D
> 
> Kind of self made NAS.
> 

   Try OpenMediaVault. It's really pretty good at this point
   and a LOT easier to use than the remaining freebies. Light
   on the CPU too, it'll actually run OK on a Pi.

   Note that if you have scripts for like copying some other
   box/nas you must create TWO mountpoints - one to the other
   box and one to localhost. Otherwise the imported data does
   not "go through the OMV system" and winds up with really
   weird permissions/indexing that makes it kinda unusable.

   I have an OMV box that backs-up a commercial NAS a few times
   a day. In case the magic smoke ever escapes the commercial box
   you only have to make three(.3) minor tweaks to OMV and it becomes
   the clone of the commercial system - all users/shares/PWs/perms/
   addresses/aliases/etc and such exactly the same. Their pwecious
   little WinBoxes will never know the diff. A five-minute disaster
   fix. A good use for a decent Gen-7 board that won't run Win-11.

   The commercial box IS "nicer", and you $$$ for that, but for most
   of our uses the OMV clone will get it done very well. USED to
   use OMV as the primary NAS, so I remembered how it worked. You
   could also spend a lot of time writing smb.conf share defs and
   craft yer own NAS (been there, done that) but NAS systems make
   all that a LOT easier and more transparent/error-free.

   With RHEL it's apparently possible to create "hot fall-over"
   servers but GEEZ ... the need/complexity is WAY beyond the
   need/scope of my current org. My alternate guy has instructions
   on how to do the change-over .. it's ONE page with some
   screenshots... the other six pages are 'technical' notes, the
   lower-level background on how it all works. I hope to
   enhance his understanding ....

Back to comp.os.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Zip list db <dieterhansbritz@gmail.com> - 2023-02-16 16:57 +0100
  Re: Zip list Bobbie Sellers <bliss@mouse-potato.com> - 2023-02-16 08:12 -0800
    Re: Zip list "25B.R866" <25B.R866@noaaba.net> - 2023-02-18 03:59 -0500
      Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-18 16:16 -0500
        Re: Zip list "25B.R866" <25B.R866@noaaba.net> - 2023-02-18 21:40 -0500
          Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-19 21:13 -0500
            Re: Zip list Computer Nerd Kev <not@telling.you.invalid> - 2023-02-20 17:19 +1000
              Re: Zip list "Carlos E. R." <robin_listas@es.invalid> - 2023-02-20 11:38 +0100
  Re: Zip list Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-02-16 16:31 +0000
  Re: Zip list Robert Heller <heller@deepsoft.com> - 2023-02-16 16:51 +0000
    Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-16 19:21 -0500
  Re: Zip list "Nuno Silva" <nunojsilva@invalid.invalid> - 2023-02-17 10:44 +0000
    Re: Zip list "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2023-02-17 10:41 -0500
      Re: Zip list Robert Heller <heller@deepsoft.com> - 2023-02-17 16:28 +0000
        Re: Zip list "Carlos E. R." <robin_listas@es.invalid> - 2023-02-17 19:06 +0100
          Re: Zip list Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2023-02-17 19:32 +0000
            Re: Zip list Bobbie Sellers <bliss@mouse-potato.com> - 2023-02-17 11:56 -0800
              Re: Zip list "Carlos E. R." <robin_listas@es.invalid> - 2023-02-17 21:10 +0100
            Re: Zip list "Carlos E. R." <robin_listas@es.invalid> - 2023-02-17 20:59 +0100
            Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-18 10:12 +0000
              Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-18 12:43 +0100
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-18 13:15 +0000
                Re: Zip list Robert Heller <heller@deepsoft.com> - 2023-02-18 14:46 +0000
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-18 17:39 +0100
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-19 11:10 +0000
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-19 12:42 +0100
                Re: Zip list "25B.E866" <25B.E866@noaaba.net> - 2023-02-22 00:58 -0500
                Re: Zip list "Carlos E. R." <robin_listas@es.invalid> - 2023-02-22 18:54 +0100
                Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-22 17:00 -0500
                Re: Zip list not@telling.you.invalid (Computer Nerd Kev) - 2023-02-23 09:23 +1000
                Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-22 19:41 -0500
                Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-22 19:43 -0500
                Re: Zip list "25B.E866" <25B.E866@noaaba.net> - 2023-02-23 01:08 -0500
                Re: Zip list "Andrei Z." <no-email@invalid.invalid> - 2023-02-23 13:32 +0300
                Re: Zip list "25B.E866" <25B.E866@noaaba.net> - 2023-02-23 11:23 -0500
                Re: Zip list "Andrei Z." <no-email@invalid.invalid> - 2023-02-23 20:29 +0300
                Re: Zip list "25B.E866" <25B.E866@noaaba.net> - 2023-02-23 21:22 -0500
                Re: Zip list Computer Nerd Kev <not@telling.you.invalid> - 2023-02-24 13:18 +1000
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 00:13 -0500
                Re: Zip list Computer Nerd Kev <not@telling.you.invalid> - 2023-02-26 12:01 +1000
                Re: Zip list "Andrei Z." <no-email@invalid.invalid> - 2023-02-24 07:58 +0300
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 00:15 -0500
                Re: Zip list "Andrei Z." <no-email@invalid.invalid> - 2023-02-25 09:34 +0300
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 02:33 -0500
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-25 10:19 +0000
                Re: Zip list Eric Pozharski <whynot@pozharski.name> - 2023-02-25 13:43 +0000
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-25 12:04 +0100
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-25 10:00 +0000
                Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-18 16:18 -0500
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-19 11:13 +0000
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-19 12:48 +0100
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 00:51 -0500
                Re: Zip list Rich <rich@example.invalid> - 2023-02-25 06:15 +0000
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 02:30 -0500
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-25 10:17 +0000
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 23:08 -0500
                Re: Zip list Robert Riches <spamtrap42@jacob21819.net> - 2023-02-26 03:46 +0000
                Re: Zip list The Natural Philosopher <tnp@invalid.invalid> - 2023-02-25 10:09 +0000
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-26 00:12 -0500
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-25 12:10 +0100
                Re: Zip list "25A.I866" <25A.I866@noacba.net> - 2023-02-25 23:41 -0500
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-26 20:22 +0100
                Re: Zip list "28A.I873" <28A.I873@noabzba.net> - 2023-02-26 23:56 -0500
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-02-27 19:26 +0100
                Re: Zip list "28A.I873" <28A.I873@noabzba.net> - 2023-02-27 22:20 -0500
                Re: Zip list Rich <rich@example.invalid> - 2023-02-28 15:21 +0000
                Re: Zip list "Carlos E.R." <robin_listas@es.invalid> - 2023-03-01 23:23 +0100
                Re: Zip list "28A.I873" <28A.I873@noabzba.net> - 2023-03-02 00:02 -0500
              Re: Zip list Andreas Kohlbach <ank@spamfence.net> - 2023-02-18 16:17 -0500
            Re: Zip list Eric Pozharski <whynot@pozharski.name> - 2023-02-18 14:55 +0000

csiph-web