Coming a bit late into this, but anyway...
On 11/18/10 08:39, "Jerome H. Fine"<jhfinedp3k at compsys.to> wrote:
Antonio wrote:
>> >>>Having (many years ago)
recovered data from a borked RT-11
>> >>>filesystem, I can certainly confirm that.
>> >>>
> >>However, I don't understand how you can use TECO to actually
> >>repair an RT-11 filesystem. For that purpose, I can only see
> >>SIPP as being able to
> >>change or repair
> >>
>I'm pretty sure I didn't say "repair"; I merely recovered data.
>
>I don't recall exactly what went wrong, but essentially I went
>in with TECO and found the right blocks for the various source
>files I needed, loaded them into TECO and wrote them out
>to floppy. Needed some minor tidy up as I recall but that's about all.
>
>
OK!! I understand completely!! If anyone else who is interested does not
understand, please ask some questions.
If the ASCII data in question was not in the first buffer, than I assume
that
something like the TECO command:
<ASstring$:;J9999K>$$
was what you used to find the start of the file which you had lost.
Well, yes and no.
What you actually do is:
ERfilename$_string$$EWnewfile$HPW$EC$EX$$
(assuming that all the data you are interested in are in the buffer,
otherwise include P commands in there to the appropriate amount, before
the HPW.)
If you really want to use A to append more data from the disk, you
should probably not use 9999K to dump the current buffer, but use HK
instead.
Also, if a search fails, you'll aready be at 0, so no reason for the J
command.
By the way, KED can do the same, but is limited to
devices (I assume that
you must have done a non-file-structured open, i.e. ERdev:$$) that are less
than 32768 blocks. Since I have never had occasion to edit a full MSCP
device of 65535 blocks, I just never noticed the limitation. This
restriction
for KED also applies to files. So KED can INSPECT a logical device which
is 32767 blocks or less or an RL02 device, but no physical device or file
larger than 32767 blocks in total.
TECO itself will not care, so that would be a limitation from the RT-11
point of view, in that case. TECO will serially read a file (or device)
from start to finish, and don't really care about
the file position
information as such.
>
>>Can you describe how you used TECO to recover data from a
> >>borked RT-11 filesystem (assuming that you did more than just
> >>READ the text contents
> >>of the files
> >>in the same manner that KED would also allow using a
> >>non-file-structured edit
> >>of the whole device)? Otherwise, if you just used TECO to
> >>just READ the
> >>text
> >>strings, please confirm that as well.
> >>
>I didn't fix a corrupt system back to a working system. I read
>blocks from disk into TECO (as you say, in a non-file structured
>mode), somehow found the root directory and worked out where the
>files I cared about lived, read each of those and saved them to floppy.
>Then either the disk was reformatted or it went back to whoever we
>bought it from for a replacement- I just don't remember.
>
More than likely, you just found the source ASCII text you were looking
for and wrote
that to the floppy file using something similar the the TECO command
that I suggested.
TECO is not designed nor able to show individual words of a specific
block as SIPP
is able to do.
Not sure what SIPP is, but TECO can handle, and display, anything. It
was designed to be able to deal with any kind of information, not just text.
>TECO can
certainly read disk block N, and having done that it can surely
>mangle that disk block; what I'm not sure of is whether it can then
>write that block out to the required disk block.
>
I really don't think so. TECO can, as far as I know, work only with
ASCII text strings.
No. TECO works perfectly fine with any kind of binary data.
Binary data can't be managed easily, if at all, by
TECO such as what
SIPP can do.
No. TECO handles binary data just fine.
Whenever you enter text, all characters are allowed. And by all
characters, I really mean all characters. Control characters are just as
welcome as printable ones. A few characters have special meaning in
TECO, such as ESC, ^C, and a few more. ESC can be used by instead
setting another character as the delimiter for the search string. Other
special control characters can be inserted by prefixing them with ^Q,
which means that the next character should be taken literally, and not
be interpreted. For most characters though, nothing special is needed at
all, and you can just enter them in your search string.
In the case you don't really want to type the control characters as
such, you can create the search string before using it, and then just
suck it into your search string as well.
In addition to this, you also have the powerful pattern matching of
search strings, that TECO gives you. So you can say that any character
should match at a specific position, and then match whatever comes after
more specifically as well (or any number of other potential pattern
matching schemes you can think of).
Johnny