19 May
2005
19 May
'05
11:08 a.m.
I have some archives that are archives of archives and intend to go
back and
extract the original archives into un-packaged treed directories then
repackage into just a zip format so that future users don't have to
figure
out the zip format to then have to figure out the myriad of CP/M
packaging/squeeze formats.
--
Verifying that all of these files are 'correct' of course..
One thing to be VERY careful of is reinjecting files that were bad and
fixed
later into reencoded archives.
When I was more active in arcade game ROM archiving, we ran into this
constantly,
where someone would find corrupt ROM data and declare them as 'new'
versions of
the game. A CRC (now SHA1) checking scheme eventually evolved to index
what had
already been shown to be correct (either though simulation or by
finding duplicates
of the physical ROMS) as well as a utility to detect when ROM dumps had
things like
stuck adr or data bits.
19 May
19 May
12:02 p.m.
There's plenty of file system meta-data out there to confound
this process. Blindly archiving and un-archiving will destroy
data that's not inside the file. There's a lot to be said for
archiving images of entire filesystems. What, timestamps
aren't important? Creation dates as well as last-modified dates?
Archive bits? At least 'tar' preserves Unix's groups and
permissions to a reasonable degree.
The Mac has always had data and resource forks and all the
cross-platform confusion that goes with them. Microsoft added
hooks to NTFS to let files have split forks like this; lately
they've been used by spyware and viruses to hide payloads.
I recall file comment fields in Amiga filenames: rarely used for
practical applications, but there none the less. Even AmigaDOS's
own operations were cruel to them; I seem to remember that
its early "copy" commands didn't copy these notes but "diskcopy"
obviously would. Similarly, even today, Windows doesn't preserve
the timestamp on directories when 'xcopy'-ing from place to place.
What, timestamps aren't valuable info?
- John
12:30 p.m.
From: "John Foust" <jfoust at threedee.com>
Sent: Thursday, May 19, 2005 2:02 PM
There's plenty of file system meta-data out there
to confound
this process. Blindly archiving and un-archiving will destroy
data that's not inside the file. There's a lot to be said for
archiving images of entire filesystems. What, timestamps
aren't important? Creation dates as well as last-modified dates?
Archive bits? At least 'tar' preserves Unix's groups and
permissions to a reasonable degree.
The Mac has always had data and resource forks and all the
cross-platform confusion that goes with them. Microsoft added
hooks to NTFS to let files have split forks like this; lately
they've been used by spyware and viruses to hide payloads.
I recall file comment fields in Amiga filenames: rarely used for
practical applications, but there none the less. Even AmigaDOS's
own operations were cruel to them; I seem to remember that
its early "copy" commands didn't copy these notes but "diskcopy"
obviously would. Similarly, even today, Windows doesn't preserve
the timestamp on directories when 'xcopy'-ing from place to place.
What, timestamps aren't valuable info?
- John
All of the tools I've been using includes the meta-data available but the
data I'm archiving is for systems that either didn't impliment such data or
as in CP/M v3 usually wasn't implimented. What meta-data is being preserved
is often when I transfered the data to DOS and the like, some may be
interested but it does not mean that a similar file with a different date is
"newer" or "older" going by the meta-date info.
Dates and hand written notes have been issues in some cases and from time to
time I've included scans of labels in the archives.
Some of the original DRI archives I sent to Gaby are examples especially of
the working disks that were never distributed outside of DRI. On these
disks that contain up to three versions (*.A86, *.BAK, and the deleted file)
of the source code being developed I included teledisk images so people
could look at these unique disks byte by byte.
On other DRI disks that were normal distribution disks I only included the
files since there was no "hidden" information not in the listed files.
Xcopy can preserve the meta-data but defaults to not keeping it (stupid
windoze).
Randy
www.s100-manuals.com
7158
days inactive
7158
days old
2 comments
3 participants
participants (3)
-
aek＠bitsavers.org -
cctalk＠randy482.com -
jfoust＠threedee.com