>Megan Gentry wrote:
> >I dont know RT-11 (yet.) and am looking forward to the experience. But
> >before that happens the seller wants to purge some sensitive employee
> >files on the system. Can someone tell me how to tell him to 1) move
> >through the directory structure, and 2) how to delete specific files (
> >some that span partitions 0 - du4 according to him ), and...
> On RT-11, as with many OSes, deletion of a file simply updates the
> directory in some way to indicate that the file is deleted. In some OSes,
> it might mean removal of the directory entry which pointed to the data on
> disk (or the list of pointers to retrieve the info). In some, it may be
> to mark the directory entry as a deleted file.
>
> In the case of RT-11, it marks the disk space taken up by the file to be
> 'free'. But until another file is written over that data, it remains,
> and can be retrieved.
>
> What they can do, however, is to delete all those files which they don't
> want anyone to have access to, and then to 'SQUEEZE' the disk volume.
> The squeeze process is similar to what Windoze does when it defragments
> a disk volume, only RT-11 files are not fragmented - they exist as
> contiguous files. But the files are all moved to the beginning of the
> disk (low block numbers) with all the free space consolidated to the
> end of the disk (higher block numbers). This will result in at least
> those deleted files which existed between others being overwritten
> with files being moved. The only problem might be a deleted file at
> the end of the volume (or if the quantity of deleted files are sufficient
> that the moved files don't adequately cover the deleted ones). It
> should be possible to write a very short program which will determine
> the last block used on the (squeezed) volume, and to write null blocks
> to all disk blocks from there to the end of the volume.
>
> Finally, RT-11 files cannot span RT-11 disk partitions. An RT-11
> file can only exist in the partition in which it is defined. It is
> possible, however, for a user application to make use of the system
> library routines which allow full access to an MSCP disk -- in which
> case doing the squeeze won't help.
>
> What you may want to suggest to him is to
>
> 1) Delete all sensitive files from all disk partitions
> 2) Squeeze all disk partitions.
> 3) backup all disk partitions (on a file, not device, basis)
> 4) FORMAT all disk partitions (RT-11 Format doesn't really
> do a low-level format except for specific devices, and
> MSCP disks are not one that it will do -- with the
> exception of RX33 diskettes)
> 5) Restore the backed-up files to all partitions.
> 6) Release the hardware to you... :-)
>
> >Where can I find a good source of RT-11 info?
>
> Not counting the documentation which can be purchased for it...
>
> right here is a good place... :-)
Jerome Fine replies:
You have omitted even a general idea of the hardware involved
like how many partitions there are and what drive is being used.
I was going to suggest the same things that Megan Gentry has noted
with some simplifications. The key is to note that, as Megan Gentry
has emphasized, the data can still be on the partition even if the
directory has been squeezed. While a format operation will likely
be the best assurance that all sensitive data has been erased, it
likely would not be satisfactory for a military requirement where
residual traces can be detected after many overwrites. Consequently,
if the managers would be satisfied with a simple zeroing of all the
potential sensitive data, then what I have done in the past under the
same circumstances is to create a 1 block file full of either all zeros
or 1s (takes much longer) with the SIPP program if you can't already
find such a block. Then, after you have squeezed all the directories
and have ONLY the permissible files left, simply copy the zero file
a number of times until you have a pile of them, maybe 10. Then
delete the 10 * 1 block files and CREATE a new 10 block file of
zeros in the same place. That leapfrogging can quickly get you a
5000 block file of all zeros and since the maximum partition can take
only 12 * 5000 blocks (plus a few more), you can fill a partition
very quickly with all zero files:
ZERO.A, ZERO.B, ZERO.C, ZERO.D, etc.
If any of the partitions are empty of all retained files, just copy
one whole partition onto another partition - not much faster,
but a little.
Once you have filled all the partitions up with ZERO.* files that
you have written yourself, there can't be anything left except
BLOCK 65535 in every RT-11 partition (except the last partition)
which is not normally available, but can be overwritten via a
COPY/DEVICE command.
Note that the use of ZERO.* files avoids the requirement of
doing a low level format operation and may be just as acceptable
as backing up all the files you want to retain. Plus, management
can actually see that all empty space has been overwritten.
I believe that Mentec sells a full set of DOCS (about 3' in the
13 binders) for about $ US 1300. You can also buy the V5.7
H-kit for about $ US 1600, or it was the last time I was
given the price. V5.7 is Y2K compatible, but Y2K patches
(obviously not the official version - and not for every single
RT-11 utility due to lack of interest) are available for V5.4G
of RT-11 and will be available for V5.3 of RT-11 by about
the 3rd quarter of 1999, sooner if there is sufficient interest,
VERY SOON if someone wants them for commercial use.
I know that Megan Gentry and many other RT-11 devotes
frown on the non-official Y2K solution for early versions
of RT-11. If anyone reading this wants to inquire, please
add your 2 cents. Anyone who insists on a complete
Y2K V5.7 of RT-11 is free (or actually "cost") to do so
at whatever price they want to pay. Of course, I have
been led to believe that Mentec will fix any bugs in V5.7
that remain, but you have better get that in writing if
you are depending on that to be done.
Sincerely yours,
Jerome Fine
RT-11/TSX-PLUS User/Addict
Received on Tue Jan 12 1999 - 12:37:03 GMT
This archive was generated by hypermail 2.3.0
: Fri Oct 10 2014 - 23:32:05 BST