From: blockedofcourse@foo.invalid
On 12/8/2025 9:28 AM, legg wrote:
> On Sun, 7 Dec 2025 19:06:21 -0700, Don Y
> wrote:
>
>> On 12/7/2025 6:24 PM, Waldek Hebisch wrote:
>>> Don Y wrote:
>>>>
>>>> I've learned to become less "discriminating" in my collections. As long
as
>>>> I can *read* the content, it's good enough for me (given that the
>>>> alternative was *paper*!).
>>>
>>> Well, I can read low quality text, but I read faster if quality is
>>> better. Sometimes it is hard to decide if there is a speck or
>>> a dot (or comma, apostrophe etc) on a page. And if you scan
>>> at larger quantity you probably do not want to proofread each
>>> page, so either you have generous margin for possible disturbances
>>> or you risk badly scanned pages.
>>
>> If I can find something, on-line, that has already been scanned,
>> it saves me the trouble of destroying a book to chop it into
>> individual pages and feed them through a scanner. So, I can
>> spend THAT time scanning something that I *can't* find on-line.
>>
>> E.g., I'd rather spend time scanning copies of _Chronobiologia_,
>> service manuals for various pieces of kit or other documents
>> than scanning a bunch of research papers that I can download,
>> regardless of their quality.
>>
>> My "library" is VERY big. Chances are, many of these "electronic
>> versions of paper documents" will not be "opened", again, in my
>> lifetime. *But*, I'd hate to be forced to choosing which to
>> preserve (regardless of quality) and which to discard.
>
> The best bet for preservation is probably to 'get it out there',
> by making it available from as many independant sources as possible,
> even if it means that some end up behind a pay wall.
This just adds another layer of effort for dubious "return".
How likely is anyone to want a copy of _Mouth Sounds_? Or,
the Mickey Mouse Club periodicals from the 1950's?
> The internet archive is good at preserving smaller files, so big
> ones should be avoided. Often, they will only preserve a link to
> a (vanished) location.
>
> A meaningful, searchable and sortable title is also helpful, at
> the earliest possible stages of file creation. Few will ever be
> able to claim a DOI or ISBN reference.
This is most important with support documents from manufacturers.
E.g., HP, TI, etc. label their files with such descriptive names
as c49820827.pdf or spr302834a.pdf.
IME, you want to preserve *that* name (so you can tell if you've already
got a copy of the file) PLUS expose the actual "title" of the document.
And, extend your "practice" to include objects that aren't, strictly
speaking, text files (e.g., binaries, source code, schematics, etc.)
that can't easily be examined by text processing tools.
I have a database that tracks the name and location of all of my
"files" in the archive. Basically, the schema is:
ID unique identifier for this record describing an object
ContainerID unique identifier for the container that holds this object
Name name of this item
So, /home/me/project1/docs/manual.pdf and /home/me/project1/enclosure.dxf
would result in entries like:
27, 105, home
8, 27, me
992, 8, project1
56, 992, docs
1073, 56, manual.pdf
47, 992, enclosure.dxf
I.e., enclosure.xf is object 47, located in 992 (which is project1) which,
in turn, is located in 8 (me) in 27 (home).
This allows me to store arbitrarily deep paths to objects (so I am not
constrained by Windows, SLOWARIS, BSD, etc.). It also lets me use
arbitrary containers:
546, 992, billing.zip
7, 546, invoices.txt
183, 546, canceled_checks.TIFF
addresses the fact that /home/me/project1/billing.zip contains the two
files invoices.txt and canceled_checks.TIFF. So, I can build an archive
file (ZIP, RAR, TGZ, etc.) containing arbitrary files and access them as
if they were "exposed" in some virtual file system.
This ALSO lets me relate individual objects to various types of meta-data
by correlating that data with an "ID" from this first table. So, I can
have another schema that records MD5's, sizes, comments, etc. about
arbitrary "objects" like:
(183, , , "Images of the canceled checks")
Note that I don't then need the object itself to be able to be annotated
with searchable information (as the object may not be suited for that).
But, it also lets me find duplicates of objects anywhere in my archive
(of course, the top level consists of identifiers for disk drives and
the machines that "contain" them!) just by searching for objects that
have the same (MD5, length).
Where this is a win is in finding a backup copy of something that may have
been corrupted or lost -- as long as the identifier and metadata are intact
(the RDBMS resides on a different host so this increases the chance of
keeping one or both). E.g., it's likely that "invoices.txt" also appears
in an archive called "1997 income tax information.tgz" as well as
"Client Tom Smith financials.arj"
Of course, it can also be used to trim the size of the whole archive! E.g.,
I DL all of the support documents, drivers, etc. for every machine that I
build and archive them locally. As many of my machines are servers, this
often includes large executables and ISOs that may be applicable to
MANY different machines. Having to store a copy with each can result in
lots of identical ~2GB files scattered throughout my archive.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
