🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #2331

Bug in Open(), and problem w/SKsh

#2331
From: Kim DeVaughn
Date: Sun, 26 Nov 1989 01:29
68 lines
3856 bytes
[ "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
Technical Details
Message-ID: <fcbb023e6d1401@amdahl.uts.amdahl.com>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!samsung!usc!apple!amdahl!kim

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!samsung!usc!apple!amdahl!kim
From: kim@uts.amdahl.com (Kim DeVaughn)
Newsgroups: comp.sys.amiga.tech
Subject: Bug in Open(), and problem w/SKsh
Keywords: Open() returns valid write lock on empty dirs, methinks.
Message-ID: <fcbb023e6d1401@amdahl.uts.amdahl.com>
Date: 26 Nov 89 01:29:28 GMT
Organization: Amdahl Corporation,  Sunnyvale, CA 94086
Lines: 68