From: Ken Smith on
In article <b33aa$45f6d225$4fe7292$20427(a)DIALUPUSA.NET>,
nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote:
>Ken Smith wrote:
>
>> In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>,
>> <jmfbahciv(a)aol.com> wrote:
>> [....]
>>
>>>>Did you write a TAPE.DIR onto the tape after the tape had already been
>>>>written?
>>>
>>>No. One of my requirements was that the file be the first in
>>>the saveset.
>>
>>
>> In other words, you created it based on what you intended to write to the
>> tape not what you actually wrote. This contradicts what you said earlier.
>>
>> It doesn't matter because the suggested method still works. The checksum
>> could still have been correct.
>
>The operative word is "could." It can never be "what was read from
>the tape." Your entire argument on this matter has been silly. It
>is an elementary problem in recursion.

Yes, it can be what was read from the tape. I explained elsewhere exactly
how you can make the first file on the tape be based on the contents of
the tape after it has been written. Tape drives can write to the start of
a tape without trashing the rest of the contents of the tape. The
operation is refered to as an "edit" write. It only requires that the
tape already contain a block of the same size. It has been done for
years.

There is no problem in recursion. There is no problem in making the
checksum correct. You seem to have missed the post where I filled you in
on how exactly the checksum of a file can be stored in the text of file
and be valid. Here is a hint:

checksum("0000ZZZZ") == checksum("1111YYYY")

You should be able to take it from there. When you figure it out try to
get BAH to understand.





--
--
kensmith(a)rahul.net forging knowledge

From: jmfbahciv on
In article <et6c0m$t53$7(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <et5un4$8ss_002(a)s887.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>>In article <et3pbr$rad$7(a)blue.rahul.net>,
>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>In article <et39hp$8ss_003(a)s948.apx1.sbo.ma.dialup.rcn.com>,
>>> <jmfbahciv(a)aol.com> wrote:
>>>>In article <et1957$ki3$2(a)blue.rahul.net>,
>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>In article <et0oi0$8qk_003(a)s776.apx1.sbo.ma.dialup.rcn.com>,
>>>>> <jmfbahciv(a)aol.com> wrote:
>>>>>>In article <esuqfn$ds3$5(a)blue.rahul.net>,
>>>>>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>>>[....]
>>>>>>>No, you are making the same mistake over and over. As I stated before,
if
>>>>>>>you know what you are going to put into TAPE.DIR, you can make its
>>>>>>>checksum correct. No editing of a magnetic tape was needed by the
>>method.
>>>>>>
>>>>>>Then that TAPE.DIR was not made by taking a directory of the
>>>>>>tape. That was not the purpose of the file. If I had to do
>>>>>>it the way you suggested, I wouldn't put the file on the tape
>>>>>>since it would be a waste of tape space.
>>>>>
>>>>>So now you are suddenly changing your story and saying that editing of
the
>>>>>tape was done.
>>>>
>>>>There was no tape editing done.
>>>
>>>In that case. The tape had to be written with the TAPE.DIR in place and
>>>correct on the first pass.
>>
>>This is the point. It will never be "correct" because the file
>>contains a checksummed listing of itself.
>>
>><snip>
>>
>>Do the exercise. Then you will see what I'm talking about.
>
>Bin thar, dun that, got t-shirt, wore out t-shirt.
>
>I've done it. The idea wasn't new when I did. You just haven't
>understood a very simple concept.

I understood you just fine. You didn't put a directory of the
tape onto the tape.

/BAH

From: jmfbahciv on
In article <et7ljd$bq1$5(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <b33aa$45f6d225$4fe7292$20427(a)DIALUPUSA.NET>,
>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote:
>>Ken Smith wrote:
>>
>>> In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>,
>>> <jmfbahciv(a)aol.com> wrote:
>>> [....]
>>>
>>>>>Did you write a TAPE.DIR onto the tape after the tape had already been
>>>>>written?
>>>>
>>>>No. One of my requirements was that the file be the first in
>>>>the saveset.
>>>
>>>
>>> In other words, you created it based on what you intended to write to the
>>> tape not what you actually wrote. This contradicts what you said earlier.
>>>
>>> It doesn't matter because the suggested method still works. The checksum
>>> could still have been correct.
>>
>>The operative word is "could." It can never be "what was read from
>>the tape." Your entire argument on this matter has been silly. It
>>is an elementary problem in recursion.
>
>Yes, it can be what was read from the tape. I explained elsewhere exactly
>how you can make the first file on the tape be based on the contents of
>the tape after it has been written. Tape drives can write to the start of
>a tape without trashing the rest of the contents of the tape.

It will trash the rest of the tape. We shipped the files within
savesets.

> The
>operation is refered to as an "edit" write. It only requires that the
>tape already contain a block of the same size. It has been done for
>years.

But your edit write would not include the directory of the tape
after you wrote it.
>
>There is no problem in recursion. There is no problem in making the
>checksum correct. You seem to have missed the post where I filled you in
>on how exactly the checksum of a file can be stored in the text of file
>and be valid. Here is a hint:
>
>checksum("0000ZZZZ") == checksum("1111YYYY")
>
>You should be able to take it from there. When you figure it out try to
>get BAH to understand.

/BAH understands your method just fine. First of all the editing
method would have trashed the first saveset. Second of all,
the file would not have been a directory of the tape after you
wrote the file to the tape.

/BAH

From: jmfbahciv on
In article <et68m3$t53$4(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <et5vdg$8qk_002(a)s887.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>>In article <et3o1m$rad$2(a)blue.rahul.net>,
>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>[....]
>>>There need not be any increase in the risk. Its all a matter of starting
>>>with a reasonable OS and not adding buffer over runs.
>>
>>There will always be buffer overruns.
>
>Only in badly written software using languages without run time checking
>does it happen. We now have more than enough CPU speed that buffer
>overruns should be a thing of the past.

You are ignoring hardware glitches, among other things. There will
always be buffer overruns. There should not be OSes who implement
them as a feature.

>
>
>> The risk of a single system
>>house site configuration is the lack of redundancy. That is
>>what makes it dangerous. The danger is not just viral infections
>>but with users typing at a system which also controls vital
>>functions within the house.
>
>I would never network my PC to my pacemaker.

But that is how the computing biz is going. I'm also thinking of
heating, security, and cooking.
>
>That said, you are assuming that the user runs as root/superuser.

I am assuming that, if it is possilbe to run privileged, there
will be a security gap. Allowing the possibility should not
be done by a system which cannot crash without serious side effects.

> I very
>rarely ever do on my home system. I do it a little more often on the work
>system but that is because I need to directly fiddle a few hardware things
>from time to time.

Then your systems aren't secure from all human hands.

/BAH

From: nonsense on
jmfbahciv(a)aol.com wrote:
> In article <et7ljd$bq1$5(a)blue.rahul.net>,
> kensmith(a)green.rahul.net (Ken Smith) wrote:
>
>>In article <b33aa$45f6d225$4fe7292$20427(a)DIALUPUSA.NET>,
>>nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote:
>>
>>>Ken Smith wrote:
>>>
>>>
>>>>In article <et5v7k$8qk_001(a)s887.apx1.sbo.ma.dialup.rcn.com>,
>>>> <jmfbahciv(a)aol.com> wrote:
>>>>[....]
>>>>
>>>>
>>>>>>Did you write a TAPE.DIR onto the tape after the tape had already been
>>>>>>written?
>>>>>
>>>>>No. One of my requirements was that the file be the first in
>>>>>the saveset.
>>>>
>>>>
>>>>In other words, you created it based on what you intended to write to the
>>>>tape not what you actually wrote. This contradicts what you said earlier.
>>>>
>>>>It doesn't matter because the suggested method still works. The checksum
>>>>could still have been correct.
>>>
>>>The operative word is "could." It can never be "what was read from
>>>the tape." Your entire argument on this matter has been silly. It
>>>is an elementary problem in recursion.
>>
>>Yes, it can be what was read from the tape. I explained elsewhere exactly
>>how you can make the first file on the tape be based on the contents of
>>the tape after it has been written. Tape drives can write to the start of
>>a tape without trashing the rest of the contents of the tape.
>
>
> It will trash the rest of the tape. We shipped the files within
> savesets.
>
>
>> The
>>operation is refered to as an "edit" write. It only requires that the
>>tape already contain a block of the same size. It has been done for
>>years.
>
>
> But your edit write would not include the directory of the tape
> after you wrote it.
>
>>There is no problem in recursion. There is no problem in making the
>>checksum correct. You seem to have missed the post where I filled you in
>>on how exactly the checksum of a file can be stored in the text of file
>>and be valid. Here is a hint:
>>
>>checksum("0000ZZZZ") == checksum("1111YYYY")
>>
>>You should be able to take it from there. When you figure it out try to
>>get BAH to understand.
>
>
> /BAH understands your method just fine. First of all the editing
> method would have trashed the first saveset. Second of all,
> the file would not have been a directory of the tape after you
> wrote the file to the tape.

I almost hate to say this, but I think that understanding
the problem is beyond him.