5 Mar
2021
5 Mar
'21
4:55 a.m.
Hello,
Someone sent me these magtape images from Tymshare and said "they fell
off the back of a truck on route 62 in Hudson, MASS." I don't know
their provenance.
Sorry, I don't have any good hosting. For now they are here:
https://gitlab.com/larsbrinkhoff/tymshare
The download.sh script will retrieve individual files one by one rather
than cloning the repository; next use cat.sh to get the .tape.bz2 files.
The tape format is close to not not quite FAILSAFE. With help from Joe
Smith, I made a tool to extract the files:
https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/tito.c
5 Mar
5 Mar
9:41 a.m.
New subject: Spelunking the places where files are not
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
It's obviously file-system dependent. At one level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
But very few systems would bother to zero out the released blocks
of erased or rewritten files and then blocks are left full of
old data. Text source code would be easy to spot.
I have vague memories of bits of Amiga OS source code being unintentionally
released in unused blocks on OS binary disks that were sent out for
mass duplication and distribution.
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
Obviously in some situations the relevant files can be pulled and
redistributed in a new filesystem like a Zip.
The situation only gets worse with distributing larger images of
entire hard disks. Or with Windows, "quick format" doesn't zero blocks.
In another case I encountered while digging through files on an old
RSTS backup tape, we had a program that logged usage data to a file
and for speed purposes it would preallocate a large file (as opposed
to extending the file, which was slower) and then write block records
to it. RSTS reused blocks without zeroing. In the unused blocks
of an extant file I found an email I'd sent in '82 as well as bits
from other users of the same timesharing system.
Certainly the archivists out there have considered these questions.
How are they solved?
Are there notable tools that focus on the files that aren't there?
I don't mean modern forensic carving tools... but some concepts would
be similar.
- John
2:24 p.m.
New subject: Spelunking the places where files are not
Three obvious possibilites for tools to help:
1) A program that makes a single large file out of all unallocated blocks,
for later study and breaak-up in an editor.
2) A prograam that makes a separate file out of each unallocated block,
for later study and appending in an editor.
3) An INTERACTIVE program that displays a block, with the option of
ignoring, or making a file out of it, and then, for each subsequent block
provides the option to Ignore, Append it to one of the existing files, or
Create a new file from it.
Ideally, it should have a clue about likely sequence of blocks, including
interleave and side patterns.
ALthough a variety of algorithms could ASSIST with whether a given block
is LIKELY to be a continuation of the previous block, few could work
stand-alone as well as a human operator.
Among the possibilities are seeing ASCII (or other) code at the end of one
block and the beginning of another ("looking for half a worm in the
apple")
The same tools are also useful when the DIRectory or other file system
information is destroyed, or completely unknown.
I had a client who was overjoyed when I gave him a few hundred files,
which he proceeded to printout and he and his staff manually sorted and
rearranged the printouts by looking at their content. We then looked at
the sequences of the file numbers and appended files accordingly.
--
Grumpy Ol' Fred cisin at xenosoft.com
On Fri, 5 Mar 2021, John Foust via cctalk wrote:
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
It's obviously file-system dependent. At one level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
But very few systems would bother to zero out the released blocks
of erased or rewritten files and then blocks are left full of
old data. Text source code would be easy to spot.
I have vague memories of bits of Amiga OS source code being unintentionally
released in unused blocks on OS binary disks that were sent out for
mass duplication and distribution.
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
Obviously in some situations the relevant files can be pulled and
redistributed in a new filesystem like a Zip.
The situation only gets worse with distributing larger images of
entire hard disks. Or with Windows, "quick format" doesn't zero blocks.
In another case I encountered while digging through files on an old
RSTS backup tape, we had a program that logged usage data to a file
and for speed purposes it would preallocate a large file (as opposed
to extending the file, which was slower) and then write block records
to it. RSTS reused blocks without zeroing. In the unused blocks
of an extant file I found an email I'd sent in '82 as well as bits
from other users of the same timesharing system.
Certainly the archivists out there have considered these questions.
How are they solved?
Are there notable tools that focus on the files that aren't there?
I don't mean modern forensic carving tools... but some concepts would
be similar.
- John
4:11 p.m.
New subject: Spelunking the places where files are not
Recovering data from disks was a lot easier 30 years ago when most
filesystems had contiguous files and it was just a matter of finding
file boundaries. Was very glad of this when accidentally wiped first
200 blocks of an RT-11 RK05 and just had to write a FORTRAN program
to copy blocks of data and assign the files names. Also wrote a
program to do a disk scan to look for specific file type and like to
show people what jpeg files they've left behind on a disk they've
"wiped". Finding images very easy as can display a list of many
image icons on screen and quickly scroll through them if one is
looking far a particular image. Of course, the longer a hard disk
has been used and not defragmented, the lower the recovery percentage
of files. Got paid for file recovery a few times but mainly use it
to show people what really happens when they "wipe" a disk. Have
convinced a lot of people that low level format on a disk they're
giving away a good idea.
After thinking about disk imaging tools like
Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
It's obviously file-system dependent. At one level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
But very few systems would bother to zero out the released blocks
of erased or rewritten files and then blocks are left full of
old data. Text source code would be easy to spot.
I have vague memories of bits of Amiga OS source code being unintentionally
released in unused blocks on OS binary disks that were sent out for
mass duplication and distribution.
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
Obviously in some situations the relevant files can be pulled and
redistributed in a new filesystem like a Zip.
The situation only gets worse with distributing larger images of
entire hard disks. Or with Windows, "quick format" doesn't zero blocks.
In another case I encountered while digging through files on an old
RSTS backup tape, we had a program that logged usage data to a file
and for speed purposes it would preallocate a large file (as opposed
to extending the file, which was slower) and then write block records
to it. RSTS reused blocks without zeroing. In the unused blocks
of an extant file I found an email I'd sent in '82 as well as bits
from other users of the same timesharing system.
Certainly the archivists out there have considered these questions.
How are they solved?
Are there notable tools that focus on the files that aren't there?
I don't mean modern forensic carving tools... but some concepts would
be similar.
- John
4:45 p.m.
New subject: Spelunking the places where files are not
On Mar 5, 2021, at 4:11 PM, Boris Gimbarzevsky via
cctalk <cctalk at classiccmp.org> wrote:
Recovering data from disks was a lot easier 30 years ago when most filesystems had
contiguous files and it was just a matter of finding file boundaries. Was very glad of
this when accidentally wiped first 200 blocks of an RT-11 RK05 and just had to write a
FORTRAN program to copy blocks of data and assign the files names.
Yes, RT11 has contiguous files. That actually made it rather unusual. For example, while
RSTS supports contiguous files that isn't the default and because of disk
fragmentation wasn't commonly used.
I was going to describe how you could do recovery on RSTS file systems, when I realized
that it doesn't actually work at all. The file system is designed to allow you to
piece it back together if some entries are corrupted. As an extreme example, in the new
(RDS 1) file structure, you could wipe out the MFD -- the root directory of the file
system -- and almost certainly put it back together by scanning the disk for the GFDs --
the second level directories, which are tagged with a magic number that allows them to be
found easily.
On the other hand, if you delete a file there is nothing left in the file system metadata
to tell you about its previous existence. While the 8-word blocks that make up directory
entries only need two leading 0 words to be considered "free", it turns out the
file system code actually zeroes all the entries in their entirety when deleting a file.
So you can try to reconstruct a file from free space, if you're lucky enough to be
able to find its pieces and connect them in the right order, but there isn't anything
left of the metadata (name, time stamps, etc.) Yes, that could have been left around, and
I'm actually somewhat puzzled about why it was done that way; it looks like early
versions (V4A at least) just zero the minimal 2 words which would leave you half a file
name and other stuff, not to mention 6/7th of the file data pointers.
paul
5:02 p.m.
New subject: Spelunking the places where files are not
On Fri, Mar 5, 2021 at 1:46 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
Yes, RT11 has contiguous files. That actually made it rather unusual. For example,
while RSTS supports contiguous files that isn't the default and because of disk
fragmentation wasn't commonly used.
On VMS you can copy files with the /CONTIGUOUS switch to specify that
the output file must occupy contiguous physical disk blocks. Of course
the default is /NOCONTIGUOUS.
I vaguely remember using the /CONTIGUOUS switch to copy MDM (MicroVAX
Diagnostic Monitor) diagnostic files from one bootable MDM disk to
another. I forget if that is necessary for proper operation of MDM.
5:08 p.m.
New subject: Spelunking the places where files are not
On Mar 5, 2021, at 5:02 PM, Glen Slick via cctalk
<cctalk at classiccmp.org> wrote:
On Fri, Mar 5, 2021 at 1:46 PM Paul Koning via cctalk
<cctalk at classiccmp.org> wrote:
I like to make RSTS floppy files contiguous to avoid spending so much time going back to
the directory to find the next set of file data pointers. In RSTS, a few files have to be
contiguous: run time systems and shared libraries, swap files, the system error message
file, and the DECtape directory buffer file. That's about it. In early versions, the
monitor had to be contiguous as well, but as of V6B that is no longer true (not for INIT
either).
Strangely enough, in the RSTS file system there are always pointers to each file cluster,
even if the file is contiguous. It didn't dawn on me until a few weeks ago that I
should have changed that -- I could have done that back around 1982 or so. Oops.
paul
Yes, RT11 has contiguous files. That actually made it rather unusual. For example,
while RSTS supports contiguous files that isn't the default and because of disk
fragmentation wasn't commonly used.
On VMS you can copy files with the /CONTIGUOUS switch to specify that
the output file must occupy contiguous physical disk blocks. Of course
the default is /NOCONTIGUOUS.
I vaguely remember using the /CONTIGUOUS switch to copy MDM (MicroVAX
Diagnostic Monitor) diagnostic files from one bootable MDM disk to
another. I forget if that is necessary for proper operation of MDM. 
6 Mar
6 Mar
2:43 a.m.
New subject: Spelunking the places where files are not
On Fri, Mar 5, 2021 at 7:41 AM John Foust via cctalk <cctalk at classiccmp.org>
wrote:
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
I've used this to recover a couple of Univation utilities from a disk that
they had been deleted from... It's quite useful... It was a FAT filesystem,
and the files were small and contiguous so it was easy...
Warner
It's obviously file-system dependent. At one
level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
But very few systems would bother to zero out the released blocks
of erased or rewritten files and then blocks are left full of
old data. Text source code would be easy to spot.
I have vague memories of bits of Amiga OS source code being unintentionally
released in unused blocks on OS binary disks that were sent out for
mass duplication and distribution.
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take
responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
Obviously in some situations the relevant files can be pulled and
redistributed in a new filesystem like a Zip.
The situation only gets worse with distributing larger images of
entire hard disks. Or with Windows, "quick format" doesn't zero blocks.
In another case I encountered while digging through files on an old
RSTS backup tape, we had a program that logged usage data to a file
and for speed purposes it would preallocate a large file (as opposed
to extending the file, which was slower) and then write block records
to it. RSTS reused blocks without zeroing. In the unused blocks
of an extant file I found an email I'd sent in '82 as well as bits
from other users of the same timesharing system.
Certainly the archivists out there have considered these questions.
How are they solved?
Are there notable tools that focus on the files that aren't there?
I don't mean modern forensic carving tools... but some concepts would
be similar.
- John
8:20 p.m.
New subject: Spelunking the places where files are not
On 3/5/21 6:41 AM, John Foust via cctalk wrote:
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
The data forensics folks are at least 20 years ahead of you, John!
They're interested in *everything* on disk, active or not.
More than 30 years ago, I posted a utility for MSDOS floppies called
"SEEJUNK". It was very revealing what could be found on manufacturers'
disks. To be fair, I also wrote a companion utility to clean the stuff
out called PRUNE.
It wasn't long after that when vendors were made aware of the issue and
took action fast.
--Chuck
8:55 p.m.
New subject: Spelunking the places where files are not
At 07:20 PM 3/6/2021, Chuck Guzis via cctalk wrote:
The data forensics folks are at least 20 years ahead of
you, John!
They're interested in *everything* on disk, active or not.
Yes, I've looked at some of the high-end tools and once wondered about
a career in data forensics. I've had a few consulting clients push
me in this direction, asking the question "what exactly was this
employee really doing?" short of a criminal investigation.
For purposes of this thread, of course, I was thinking about all
the old file systems. I imagine the expensive packages don't handle,
say, UCSD Pascal or RT-11 or Amiga disk file systems, right?
But I bet they handle FAT and NTFS and Mac and Unix/Linux.
One feature from the big-boy software that would be nice to
carry down to the old stuff would be lists of known OS files
so they could be subtracted from disks (thereby leaving the
user-created stuff.)
More than 30 years ago, I posted a utility for MSDOS
floppies called
"SEEJUNK".
https://lostarchives.org/category/27/file/2258#
And I guess I hadn't thought of that case where the file system
named the number of bytes in the file and that the unused ends
of blocks could also contain stuff, too. Is there a name for those bytes?
It was very revealing what could be found on
manufacturers'
disks.
Such as?
To be fair, I also wrote a companion utility to clean
the stuff
out called PRUNE.
And Microsoft is still handing out a zeroing tool, useful in several
situations including thinning virtualized drives.
https://docs.microsoft.com/en-us/sysinternals/downloads/sdelete
- John
7 Mar
7 Mar
11:30 a.m.
New subject: Spelunking the places where files are not
At 07:55 PM 3/6/2021, John Foust via cctalk wrote:
And I guess I hadn't thought of that case where the
file system
named the number of bytes in the file and that the unused ends
of blocks could also contain stuff, too. Is there a name for those bytes?
An interesting analysis of "slack bytes" on the IBM DOS 1.0 disks.
https://thestarman.pcministry.com/DOS/ibm100/Exam.htm
- John
8 Mar
8 Mar
4:16 a.m.
New subject: Spelunking the places where files are not
On Fri, 5 Mar 2021 at 15:41, John Foust via cctalk
<cctalk at classiccmp.org> wrote:
After thinking about disk imaging tools like Greaseweasel,
I started thinking about tools that would grab and examine the unused
portions of disks.
It's obviously file-system dependent. At one level we know of
"undelete" tools that could piece together recently deleted files
and restore them intact by using abandoned bits of block table info.
Of course some simple file systems can't even permit that.
Linux distros come with a standard tool to do some of that,
'testdisk'. From the overview:
"Partition scanner and disk recovery tool"
It works with :
* DOS/Windows FAT12, FAT16 and FAT32
* NTFS ( Windows NT/2K/XP )
* Linux Ext2 and Ext3
* BeFS ( BeOS )
* BSD disklabel ( FreeBSD/OpenBSD/NetBSD )
* CramFS (Compressed File System)
* HFS and HFS+, Hierarchical File System
* JFS, IBM's Journaled File System
* Linux Raid
* Linux Swap (versions 1 and 2)
* LVM and LVM2, Linux Logical Volume Manager
* Netware NSS
* ReiserFS 3.5 and 3.6
* Sun Solaris i386 disklabel
* UFS and UFS2 (Sun/BSD/...)
* XFS, SGI's Journaled File System
.
PhotoRec is file data recovery software designed to recover
lost pictures from digital camera memory or even Hard Disks.
It has been extended to search also for non audio/video headers.
It searches for following files and is able to undelete them:
* Sun/NeXT audio data (.au)
* RIFF audio/video (.avi/.wav)
* BMP bitmap (.bmp)
* bzip2 compressed data (.bz2)
* Source code written in C (.c)
* Canon Raw picture (.crw)
* Canon catalog (.ctg)
* FAT subdirectory
* Microsoft Office Document (.doc)
* Nikon dsc (.dsc)
* HTML page (.html)
* JPEG picture (.jpg)
* MOV video (.mov)
* MP3 audio (MPEG ADTS, layer III, v1) (.mp3)
* Moving Picture Experts Group video (.mpg)
* Minolta Raw picture (.mrw)
* Olympus Raw Format picture (.orf)
* Portable Document Format (.pdf)
* Perl script (.pl)
* Portable Network Graphics (.png)
* Raw Fujifilm picture (.raf)
* Contax picture (.raw)
* Rollei picture (.rdc)
* Rich Text Format (.rtf)
* Shell script (.sh)
* Tar archive (.tar )
* Tag Image File Format (.tiff)
* Microsoft ASF (.wma)
* Sigma/Foveon X3 raw picture (.x3f)
* zip archive (.zip)
I haven't used the tool recently, but some ten-fifteen years ago there
was for some reason much more disk trouble and I used the tool
effectively to recover lost data and partitions.
7:09 a.m.
New subject: Spelunking the places where files are not
On 2021-03-05 09:41, John Foust via cctalk wrote:
This situation makes me hesitant to release disk images from the past.
It's one thing to do it with disks that were mine and to take responsibility
for my risk; it's another to release disks once owned and used by others.
Do the unused sectors contain their love letters from 1983?
Or if I want to release disk images that contain known personal files,
how will I image, then remove specific files, then zero unused blocks
if I don't want to alter the original media?
I started to do something in this direction, using a lot of virtual
machines ...
Before I make backups, I write a file with zero content, until it fills
up the filesystems (something like dd if=/dev/zero of=/ttt.tmp ; rm ttt.tmp)
Two benefits:
a.) there shouldn't be any hidden stuff anymore
b.) the file containers can be zipped nicely, as all unused stuff is zero
Hope it helps ...
5 Mar
5 Mar
10:45 a.m.
On Fri, Mar 5, 2021 at 4:55 AM Lars Brinkhoff via cctalk <
cctalk at classiccmp.org> wrote:
Hello,
Someone sent me these magtape images from Tymshare and said "they fell
off the back of a truck on route 62 in Hudson, MASS." I don't know
their provenance.
Sorry, I don't have any good hosting. For now they are here:
https://gitlab.com/larsbrinkhoff/tymshare
The download.sh script will retrieve individual files one by one rather
than cloning the repository; next use cat.sh to get the .tape.bz2 files.
The tape format is close to not not quite FAILSAFE. With help from Joe
Smith, I made a tool to extract the files:
https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/tito.c
I'm not having any luck with either back10 or tito.
$ sha1sum 169249.tape
1230fb20086990a1ff777fce32591f2900425694 169249.tape (So that's good)
$ ./tito -x -f 169249.tape
fopen: Is a directory
$ bin/back10 -l -f 169249.tape | head
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700202].ufd
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700004].ufd
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700220].ufd
$ bin/back10 -x -f 169249.tape
...
that gets lots of files with names like 'dsk:[1,4]specdf525].mic'
That just seems wrong.
1:37 p.m.
Tony Aiuto wrote:
that gets lots of files with names like
'dsk:[1,4]specdf525].mic'
That just seems wrong.
Correct, back10 does get some things wrong. It also puts some data at
the beginning of files which should be part of the file header. TITO
uses the "*FAILSAFE" magic number which fools back10 to think it's
FAILSAFE.
What problem do you have with my tito tool? Which tape did you try?
I haven't tested all tapes, so maybe some of them has surprises.
I'm not sure what to do with the file checksum yet.
8:17 p.m.
On Fri, Mar 5, 2021 at 1:37 PM Lars Brinkhoff <lars at nocrew.org> wrote:
Tony Aiuto wrote:
Like I said before
$ ./tito -x -f 169249.tape
fopen: Is a directory
$ bin/back10 -l -f 169249.tape | head
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700202].ufd
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700004].ufd
18-Nov-1858 00:00:00 <754> dsk:[1,1][3,700220].ufd
$ bin/back10 -x -f 169249.tape
that gets lots of files with names like 'dsk:[1,4]specdf525].mic'
that gets lots of files with names like
'dsk:[1,4]specdf525].mic'
That just seems wrong.
Correct, back10 does get some things wrong. It also puts some data at
the beginning of files which should be part of the file header. TITO
uses the "*FAILSAFE" magic number which fools back10 to think it's
FAILSAFE.
What problem do you have with my tito tool? Which tape did you try?
I haven't tested all tapes, so maybe some of them has surprises.
I'm not sure what to do with the file checksum
yet.
That is useful to verify that we reassembled the pieces correctly.
$ sha1sum 169249.tape
1230fb20086990a1ff777fce32591f2900425694 169249.tape
This matches yours.
6 Mar
6 Mar
1:54 a.m.
Tony Aiuto wrote:
This appears to be because creating an output file was attempted, but
there was already a directory there with the same name. I'm updating
the program to print better error messages.
What problem
do you have with my tito tool?
$ ./tito -x -f 169249.tape
fopen: Is a directory
8:07 p.m.
On Sat, Mar 6, 2021 at 1:54 AM Lars Brinkhoff <lars at nocrew.org> wrote:
Tony Aiuto wrote:
This appears to be because creating an output file was attempted, but
there was already a directory there with the same name. I'm updating
the program to print better error messages.
I think that is an artifact of the files being created with the wrong names.
For example, with tape 169249, after you skip the UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
What
problem do you have with my tito tool?
$ ./tito -x -f 169249.tape
fopen: Is a directory 
11:47 p.m.
On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk
<cctalk at classiccmp.org> wrote:
I think that is an artifact of the files being created
with the wrong names.
For example, with tape 169249, after you skip the UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
7 Mar
7 Mar
3:03 a.m.
Jim Carpenter wrote:
Tony Aiuto wrote:
I have no idea what could make that happen. I made some improvements to
tito.c, so please try the latest version.
(I also have a dart.c in the works for WAITS tapes. Mostly useful if
you're running WAITS and want to transfer files in and out.)
I think that is an artifact of the files being
created with the wrong
names. For example, with tape 169249, after you skip the UFDs, tito
-t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
[...]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
[...]
8 Mar
8 Mar
11:15 a.m.
On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter <jim at deitygraveyard.com>
wrote:
On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk
<cctalk at classiccmp.org> wrote:
Well. I'm stumped right now. I verified the tape checksum again, and even
got a fresh copy from http://vtda.org/bits/software/DEC/PDP-10/tymshare/.
That is not the problem.
I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
8.3.0) so I doubt this is a portability problem. I'll try again next
weekend.
I think that is an artifact of the files being
created with the wrong
names.
For example, with tape 169249, after you skip the
UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
5:43 p.m.
On Mon, Mar 8, 2021 at 9:16 AM Tony Aiuto via cctalk <cctalk at classiccmp.org>
wrote:
On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter <jim
at deitygraveyard.com>
wrote:
Compile -O0? Maybe there's some UB behavior that's screwing you up...
Warner
On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via
cctalk
<cctalk at classiccmp.org> wrote:
Well. I'm stumped right now. I verified the tape checksum again, and even
got a fresh copy from http://vtda.org/bits/software/DEC/PDP-10/tymshare/.
That is not the problem.
I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
8.3.0) so I doubt this is a portability problem. I'll try again next
weekend.
I think that is an artifact of the files being
created with the wrong
names.
For example, with tape 169249, after you skip the
UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
6:22 p.m.
On Mon, Mar 8, 2021 at 11:16 AM Tony Aiuto <tony.aiuto at gmail.com> wrote:
I'm building tito on a generic Debian linux
(x86_64, debian 4.19, gcc 8.3.0) so I doubt this is a portability problem. I'll try
again next weekend.
Linux jim-xubuntu 5.8.0-44-generic #50-Ubuntu SMP Tue Feb 9 06:29:41
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0
If it makes you feel any better, I can't figure out how to get back10
to extract all files. :) I have to give the file names to extract.
Jim
9 Mar
9 Mar
12:58 a.m.
Jim Carpenter wrote:
If it makes you feel any better, I can't figure
out how to get back10
to extract all files. :) I have to give the file names to extract.
It does have some quirk. The names are matched exactly, or as regexp.
I think an '' empty string works, or maybe '.*'. And it's best to
start
in an empty directory
8 Mar
8 Mar
6:40 p.m.
Tony Aiuto wrote:
On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter <jim
at deitygraveyard.com> wrote:
Out of curiosity, I tried building tito on VMS (with DECC V7.3-009 on an
Alphaserver 800). I had some errors compiling memory.c but it appears
the code involved does not get called by tito so this didn't cause me
any problems. I was able to list the contents of tape 169249 with the
resulting executable and the output I got matched the "right" output
above exactly. I didn't see anything that looked wrong elsewhere in the
file listing either.
Regards,
Peter Coghlan.
On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via
cctalk
<cctalk at classiccmp.org> wrote:
Well. I'm stumped right now. I verified the tape checksum again, and even
got a fresh copy from http://vtda.org/bits/software/DEC/PDP-10/tymshare/.
That is not the problem.
I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
8.3.0) so I doubt this is a portability problem. I'll try again next
weekend.
I think that is an artifact of the files being
created with the wrong
names.
For example, with tape 169249, after you skip the
UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
8:55 p.m.
It's a buffer overrun. sixbit_to_ascii writes 7 bytes. The extension was
declared as 4. Changing to 7 is required. I'm not sure if that is the only
fix yet. I have not had time for a detailed inspection.
- char ext[4];
+ char ext[7];
On Mon, Mar 8, 2021 at 6:57 PM Peter Coghlan via cctalk <
cctalk at classiccmp.org> wrote:
Tony Aiuto wrote:
even
On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter
<jim at deitygraveyard.com>
wrote:
On Sat,
Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk
<cctalk at classiccmp.org> wrote:
Well. I'm stumped right now. I verified the tape checksum again, and I think that is an artifact of the files being
created with the wrong
names.
For example, with tape 169249, after you skip the
UFDs, tito -t prints
(SYS) .SHR 1977-01-26 22:22 [1,4]
(SYS) .LOW 1977-01-26 22:23 [1,4]
(SYS) .SHR 1986-08-19 03:53 [1,4]
(SYS) .LOW 1975-10-24 14:52 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
(SYS) .SAV 1964-01-02 00:01 [1,4]
All the file names are missing. That seems not right.
Very not right, because this is what tito -t is giving me:
(SYS) PIP .SHR 1977-01-26 22:22 [1,4]
(SYS) PIP .LOW 1977-01-26 22:23 [1,4]
(SYS) LOGINN.SHR 1986-08-19 03:53 [1,4]
(SYS) COBOL .LOW 1975-10-24 14:52 [1,4]
(SYS) BINCON.SAV 1964-01-02 00:01 [1,4]
(SYS) VPDATA.SAV 1964-01-02 00:01 [1,4]
Those are the first 6 after the UFDs, and extensions and
date/timestamps match yours. I don't have any, at least on 169249,
missing the first part of the file name.
Jim
got a fresh copy from
http://vtda.org/bits/software/DEC/PDP-10/tymshare/
.
That is not the problem.
I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
8.3.0) so I doubt this is a portability problem. I'll try again next
weekend.
Out of curiosity, I tried building tito on VMS (with DECC V7.3-009 on an
Alphaserver 800). I had some errors compiling memory.c but it appears
the code involved does not get called by tito so this didn't cause me
any problems. I was able to list the contents of tape 169249 with the
resulting executable and the output I got matched the "right" output
above exactly. I didn't see anything that looked wrong elsewhere in the
file listing either.
Regards,
Peter Coghlan.
6 Mar
6 Mar
11:48 a.m.
Tony Aiuto wrote:
I phrased that poorly.
What I meant was the checksum that is stored on the tape along with each
file. Or at least that's what the documentation says. To me it looks
like some files have it, others don't.
I'm not
sure what to do with the file checksum yet.
That is useful to verify that we
reassembled the pieces correctly.
7 Mar
7 Mar
4:25 a.m.
The tapes are now hosted here:
http://vtda.org/bits/software/DEC/PDP-10/tymshare/
1231
days inactive
1235
days old
29 comments
13 participants
participants (13)
-
boris＠summitclinic.com -
cclist＠sydex.com -
cctalk＠beyondthepale.ie -
cisin＠xenosoft.com -
emu＠e-bbes.com -
glen.slick＠gmail.com -
imp＠bsdimp.com -
jfoust＠threedee.com -
jim＠deitygraveyard.com -
kspt.tor＠gmail.com -
lars＠nocrew.org -
paulkoning＠comcast.net -
tony.aiuto＠gmail.com