[comp.sys.amiga.tech] Bug in Open

kim@uts.amdahl.com (Kim DeVaughn) (11/26/89)

[ "All sweet things have one thing in common ... a tendency to make you sick." ]
[                                    --Soolin                                  ]

Here is a problem that I just ran into that may (or may not) be responsible
for some of those unexplained filesystem crashes where all of a sudden you
get a requester informing you that "Blah: has a read/write error".  Maybe
someone else can shed some light on this ...

It's easy to recreate, and occurs on both the FFS and the OFS (under 1.3.2),
though I'd recommend trying it out on a floppy :-)   Just make an empty
directory, and then "edit" it.  The empty dir has been transformed into a
file following the editor's "save" operation (at least when using Matt's DME
[v1.31], or mg2a, or CBM's MEmacs [v1.3]).  I dunno about other editors ...

Some "touch" routines will also cause this to happen (specifically, the
"touch" routine in SKsh v1.2).

More specifically, both  fib->fib_DirEntryType	and  fib->fib_EntryType  get
changed from a positive value, which indicates a directory (I've only ever
seen the value of 2), to a negative value, indicating a file (-3 is the one
I always see).

Presumably, none of these programs check to see what kind of "object" they're
being asked to edit/touch/whatever ahead of time :-(   They do fail (usually)
when they attempt to get a write-lock from Open() to write the modified "file"
contents, but apparently Open() returns a valid (?) write-lock if the file is
really an empty directory!  [This is my speculation on what's going on.]

Now I dunno if this problem can really damage anything ... seems like we just
turned an empty dir into a normal file.  But I don't know that for *sure*,
and I'd like CBM and/or others to take a look at it (copy of this going to
bugs@cbmvax.com).


As may be ... I encountered the above bug while putting the v1.2 version of
Steve Koren's absolutely EXCELLENT SKsh shell thru it's paces and seeing if
his implementation of "touch" worked correctly (it does, but for the above
problem).

However, there is another bug in SKsh that I found that resulted in the "Ye
Olde read/write error requester" popping up.  Seems that SKsh (v1.2) lets you
"cd" into any object (if that makes any sense), be it directory, file, 0-length,
or not.  And whilst "inside" a file (wherever that is), uglyness may befall
you in unpredictible ways depending on what you're trying to do.  In any case,
the filesystem(s) got terribly confused, bringing up the read/write requester
on occasion (though I don't *think* any damage was done, as they were all
read operations), and "fireworks" once ...   Oh, and the lock doesn't always
go away after cd'ing "out" of the file.


Bottom line: there seems to be a bug in Open() to an empty dir for a write.
Editors and the like ought to check the type of object they're being asked
to operate on (you don't edit directories ... sector editors excepted).  And
you don't "cd" into files (how *are* you managing this trick, Steve ?).


Now back to wringing out SKsh ... it is truly a fine program, and an excellent
implementation of a UN*X-like shell!  Finally!	Thank you Steve!!!

/kim

-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
BIX:   kdevaughn     GEnie:   K.DEVAUGHN     CIS:   76535,25

koren@hpfelg.HP.COM (Steve Koren) (11/27/89)

>Presumably, none of these programs check to see what kind of "object" they're
>being asked to edit/touch/whatever ahead of time :-(   They do fail (usually)
>when they attempt to get a write-lock from Open() to write the modified "file"
>contents, but apparently Open() returns a valid (?) write-lock if the file is
>really an empty directory!  [This is my speculation on what's going on.]

I'll look into it and fix it in the next version.  It will be easy to fix.

>However, there is another bug in SKsh that I found that resulted in the "Ye
>Olde read/write error requester" popping up.  Seems that SKsh (v1.2) lets you
>cd into any object (if that makes any sense), be it directory, file, 0-length,
>or not.  And whilst "inside" a file (wherever that is), uglyness may befall
   .....
> you don't "cd" into files (how *are* you managing this trick, Steve ?).

Well, I just check the return code from the chdir() call.  I don't remember
right now if I use Lattice's or the AmigaDos one.  Anyhow, if the chdir() fails
then I report an error.  Maybe chdir() isn't failing when it should be.
I guess I can fix it by checking the object type explicitly.

> [ksh type gratitude sufff] Finally!  Thank you Steve!!!

   You bet.  This seemed like a void in the Amiga software world begging
to be filled.

             - steve