Disappearing Pascal files
Willi Kusche
I've been using Apple II System Utilities or Chameleon to transfer
files from ProDOS volumes to Apple Pascal volumes only to have them
disappear from the Pascal volume. The files will transfer OK as shown
by displaying a catalog of the destination volume after the transfer
is completed. But after booting Apple Pascal the file doesn't show up
in a catalog listing.
I have been able to get Apple Pascal to find the file by using the
M)ake command in the Filer. But the resulting file size is too big.
So going back to ProDOS and transferring the file again results in the
correct file size on the Apple Pascal volume. Now, the Filer will
show the desired file.
Anyone know what's going on?
Willi
John B. Matthews
a...@wilserv.com (Willi Kusche) wrote:
I did some testing with Apple Pascal II 1.3, ProDOS 2.0.3 and
Apple System Utilities 3.1. I was unable to reproduce this
effect when the volume was K(rnch'd.
When Pascal's Filer removes consecutive files, the directory is
updated to reflect a single <UNUSED> block. When I tested
volumes with <UNUSED> blocks created by the Pascal Filer, I had
no problem.
When I use System Utilities to remove files, I get multiple
consecutive <UNUSED> entries or spurious deletion of the last
entry even when it wasn't marked. System Utilites claims the
last file is still present, but the Filer can't see it (absent
the make command).
I would have to say that, under certain circumstances, System
Utilties 3.1 under ProDOS 2.0.3 does not correectly delete files
from a Pascal volume.
BTW, when you use the Filer's M(ake, you can specify a size: eg.
#4:f1.text[4]. As I recall, [0] means all of the largest unused
space; [*] means half the largest or all of the second largest
space, whichever is greater.
John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
Willi Kusche
"John B. Matthews" <nos...@nospam.com> wrote in message news:<nospam-AC2146....@news-server-fe-02.columbus.rr.com>...
> I did some testing with Apple Pascal II 1.3, ProDOS 2.0.3 and
> Apple System Utilities 3.1. I was unable to reproduce this
> effect when the volume was K(rnch'd.
You weren't able to duplicate my problem because you haven't
patched your copy of ProDOS to remove the logic that ensures that the
year in the ProDOS date field is less than 100.
It's now apparent that Apple Pascal checks all volumes that are
on-line during the boot process and deletes any files that have "bad"
dates.
Willi
Michael J. Mahon
Some more fallout from making the "unauthorized" Y2K patch
to ProDOS...
Apple's standard was that any two-digit date less than 40 would
be interpreted as 20xx, and the field would never go over 99.
-michael
Check out parallel computing for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/
Willi Kusche
mjm...@aol.com (Michael J. Mahon) wrote in message news:<20040816020647...@mb-m07.aol.com>...
> Apple's standard was that any two-digit date less than 40 would
> be interpreted as 20xx, and the field would never go over 99.
Screw Apple's standard. The standards should be set by the people
who are writing code NOW.
Willi
John B. Matthews
a...@wilserv.com (Willi Kusche) wrote:
I believe my ProDOS 2.0.3 is unpatched, but I still see files
that were created by Pascal 1.3, _not_ deleted by System
Utilties 3.1, disappear when examined subsequently with the
Pascal 1.3 Filer.
You assert that Pascal is doing this? Could it be System
Utilities choking on bogus dates inserted by Pascal 1.3?
I admit, I was startled to see how Pascal deletes files. Looks
like I better type in my Pascal disk zap program from its
listing:-)
Kelly Hall
> Screw Apple's standard. The standards should be set by the people
> who are writing code NOW.
Exactly. So why don't both of you work it out?
Kelly
Michael J. Mahon
Sure, but changing things risks failure of code written THEN,
like Pascal.
Choosing to use values of a representation that go beyond what
was expected by any existing software can be predicted to cause
problems with already-existing software. And, unless you plan to
write everything you need from scratch, compatibility with already-
existing software is a significant requirement.
Standards and architecture are about enabling _orderly_ evolution
without breaking existing code. And anyone writing code NOW
had better keep that in mind if they expect anyone to bother
using their code.
Apple described a method for extending the range of Apple II
date formats until 2039 which would have minimal impact on
pre-existing code. People who decided on a different method,
like using year values that go beyond 99, did so at their peril.
The breakage with Pascal is one example of the downside.
The difference between a hack and a well thought-out design
is the careful tradeoff between new capability and compatibility
with existing code.
Willi Kusche
mjm...@aol.com (Michael J. Mahon) wrote in message news:<20040817040000...@mb-m16.aol.com>...
Well said. But, on all the systems at this location, the year
field in the ProDOS date has the values 100 to 104 to represent the
years 2000 to 2004. All the programs that I use, that display a date,
have been patched, re-assembled or re-compiled to allow values over
100.
I'm in the process of recreating the source for version 1.1 of
Apple Pascal so changing it to handle year values over 100 will be
possible.
I don't like the way Apple set the standard. So, I won't abide by
it. And, I'll fix anything that breaks. Why not, I'm SuperProgrammer.
;)
Willi
Hans Otten
>
> I'm in the process of recreating the source for version 1.1 of
>Apple Pascal so changing it to handle year values over 100 will be
>possible.
>
> I don't like the way Apple set the standard. So, I won't abide by
>it. And, I'll fix anything that breaks. Why not, I'm SuperProgrammer.
> ;)
\well said Willi! A fun project, looking forward to the results!
Hans, http://www.hansotten.com
Michael J. Mahon
As long as you're having fun with it, more power to you!
But the original post was describing a problem brought on by
the design decision to use year numbers beyond 99. That's
what I was responding to.
Any scheme can be made to work, given enough effort.
This approach is practical for a single individual or a small,
coherent community of users who are willing to standardize
on a subset of applications that interoperate using the chosen
design.
The problem comes when a larger, less coherent (!) user
community is involved, with _lots_ of application and utility
programs. This is the environment in which standards
are important, and multiple "standards" are a real PITA.
(BTW, what are your plans for the year 2028? ;-)
Willi Kusche
"John B. Matthews" <nos...@nospam.com> wrote in message news:<nospam-4AC045....@news-server.woh.rr.com>...
> You assert that Pascal is doing this? Could it be System
> Utilities choking on bogus dates inserted by Pascal 1.3?
Something in the Pascal boot process is doing the dirty deed. I
just did a test that you ought to able to reproduce. I used a ProDOS
sector editor on the directory of a Pascal disk to change the two byte
date field of a Pascal file from what it was to all bits set ($FFFF).
Then I booted into Apple Pascal 1.1. Finally, I booted back into
ProDOS without using the Filer while in Pascal. Use of Apple System
Utilities revealed that the file had been deleted.
To restore the file so that it could be seen by the Filer, I
restored the file count, the length of the file name and the file's
date from ProDOS via a sector editor. Upon returning to Pascal, the
file could be seen by the Filer.
Willi
John B. Matthews
Indeed, I can reproduce your findings. Moreover, any date with
year > 99 (e.g. 15-Aug-100 = $F8C8) causes the p-system to hose
the entry at boot time. Urghh!
Michael J. Mahon
If I were doing a date validity check I would do the same
thing...just as I would check for 0<month<13, etc.
John B. Matthews
An interesting point. The Pascal declaration for the date field
(a packed record) implies a run-time range check, but that check
is usually turned off for efficiency. Clearly, code that enters
a date must avoid malformed data; but code that reads the date
merely has to display & sort sensibly, for whichever Y2K scheme
is used. I use Apple's scheme, but I admire Willi's fortitude in
assaying the other approach:-)
I would argue that _deleting_ a file with a malformaed date at
boot time is a bit heavy handed. It's as if fsck quietly deleted
broken inodes! Recalling that this goes back to version 1.1,
were the implementers protecting the file system from some
greater damage?
Michael J. Mahon
>In article <20040818040952...@mb-m01.aol.com>,
> mjm...@aol.com (Michael J. Mahon) wrote:
>
>> John B. Matthews wrote:
<snip>
>> >Indeed, I can reproduce your findings. Moreover, any date with
>> >year > 99 (e.g. 15-Aug-100 = $F8C8) causes the p-system to hose
>> >the entry at boot time. Urghh!
>>
>> If I were doing a date validity check I would do the same
>> thing...just as I would check for 0<month<13, etc.
>>
>> -michael
>
>An interesting point. The Pascal declaration for the date field
>(a packed record) implies a run-time range check, but that check
>is usually turned off for efficiency. Clearly, code that enters
>a date must avoid malformed data; but code that reads the date
>merely has to display & sort sensibly, for whichever Y2K scheme
>is used. I use Apple's scheme, but I admire Willi's fortitude in
>assaying the other approach:-)
>
>I would argue that _deleting_ a file with a malformaed date at
>boot time is a bit heavy handed. It's as if fsck quietly deleted
>broken inodes! Recalling that this goes back to version 1.1,
>were the implementers protecting the file system from some
>greater damage?
I agree that deleting the "file" without a warning is heavy-handed.
Perhaps they assumed that an invalid date meant that the whole
directory entry could not be trusted--after all, it was correct when
they wrote it. ;-)
Of course, if that's the case, then it is inappropriate to trust the
start and length of the file, as well, so deletion is still suspect.
Pascal was always a bit authoritarian about its run-time model...
Andy McFadden
> Of course, if that's the case, then it is inappropriate to trust the
> start and length of the file, as well, so deletion is still suspect.
I'm not sure what you mean. Deleting the file just leaves a hole, whether
the start and length are correct or not.
--
Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
CD-Recordable FAQ - http://www.cdrfaq.org/
CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
Michael J. Mahon
>Michael J. Mahon <mjm...@aol.com> wrote:
>> Of course, if that's the case, then it is inappropriate to trust the
>> start and length of the file, as well, so deletion is still suspect.
>
>I'm not sure what you mean. Deleting the file just leaves a hole, whether
>the start and length are correct or not.
My mistake.
I'm not familiar with the Pascal directory data structures. I had
forgotten just how primitive the Pascal file system is.
Andy McFadden
> I'm not familiar with the Pascal directory data structures. I had
> forgotten just how primitive the Pascal file system is.
What it lacks in sophistication it more than makes up for in speed. ;-)
Willi Kusche
"John B. Matthews" <nos...@nospam.com> wrote in message news:<nospam-08E935....@news-server-fe-02.columbus.rr.com>...
> Indeed, I can reproduce your findings. Moreover, any date with
> year > 99 (e.g. 15-Aug-100 = $F8C8) causes the p-system to hose
> the entry at boot time. Urghh!
I came up with a patch for Apple Pascal 1.1 to fix this problem.
Use a hex editor to search for hex string $A20C0709BA64C48DA1 in the
disk APPLE1:. Change the $64 to $7F.
Thanks to all who posted messages in this thread, especially John.
John's initial response to my description of the disappearing file
problem inspired me to make images of disks and compare them. When I
saw that the only difference between "good" and "bad" images was in
the date field, I had the clue I needed.
Willi