Re: mkshlib mysteries

[Eric_Jacobs@fc.mcps.k12.md.us (Eric Jacobs) writes:]

>Ok, ok, I answered my own question. It turns out, most programs
>won't even run correctly unless their BSS is preset to zero. So,
>it is essential that zeroes are written when ld seeks past the end-
>of-file. Here is rcsdiff -r1.24 -r1.13 rw.c for vstafs.

Thanks, I'll go over this diff.

>The major snags I've run into running vstafs as my main partition are:
>
>1. File names. All of the archives are taken from dos, which truncates
>the names to 8.3 and disregards capitalization. So, expect to do a lot
>of
>renaming of files.

Hmmm, I mostly tried to avoid such filenames in the first place. MGR will
have a problem, but if you want to send me a list of others, I'll see what
can be done.

>2. Security/permissions. Again, something is ignored by dos (mostly).
>The shared libraries in /vsta/lib must have read-access by everyone.
>Also, init gets sys.sys, but not the "real root". So /vsta/etc/passwd
>and
>/vsta/etc/shadow must be sys.sys readable. Rcs has a problem that I
>haven't figured out. Whenever I check-in a file, the corresponding
>file in the RCS directory is not readable by anyone (not even root). It
>can
>be rm'd, but that's about it. I cannot even chmod it.

Yes, having lived with the current security treatment of vstafs, I'm about
ready to put my head together with anybody who wants to talk about some sort
of generalized "umask" concept.

>3. The problem involving writing after seeking past the end-of-file.
>
>Right now I'm trying to make a slight change to the C library in open()
>so that if a file is being created in a path and the directories don't
>already exist, open will create them as it walks the path. This
>behavior
>seems to be required by tar. Has anyone else encountered this problem?

No, tar(1) has a clue how to handle this (see make_dirs()), as does "mkdir
-p" (see how it uses "pflag"). open() should not do this, as you'll crash
into POSIX and probably make various utilities in subtle ways.

>XXContent-Type: application/octet-stream; name="RWDIFF"
>XXContent-ID: <msg919913.thr-1955d01.10cf5d.part2@fc.mcps.k12.md.us>
>XXContent-Transfer-Encoding: base64
>...

FYI, the mailing list clamps down on things which look like binary
attachments. In this case, I'll extract this from the filtered input, and
apply the diffs as appropriate.

Sounds like you're having fun messing with this style of root filesystem!

I've put some more time in on the "corrupted GNU as" bug. It comes down to
a race condition between the sync of buffers on the close of the "as"
utility, and the buffer operations of the next couple of files. I've been
messing with some trip points, and haven't nailed it down further, except
that I now know that a lot of things I *thought* worked OK, in fact *do*
work OK.

                                                Regards,
                                                Andy Valencia
Received on Sun Nov 8 18:15:32 1998