Coda File System

Aha!! vfs_open revisited

From: Peter Braam <braam_at_cs.cmu.edu>
Date: Fri, 17 Apr 1998 16:39:58 -0400 (EDT)
Remember all the discussion we had in the Coda meeting regarding confusion
about flags passed to the upcalls for open and create.  Well 3 months
later, here is a clue as to why. 

The key observation we made earlier was that a system call "create" or
"open" with the O_CREAT flag, breaks into two VFS operations:
"vfs_create" and "vfs_open" (BSD notation, Linux is similar).  Both give
rise to upcalls:  "coda_create" and "coda_open" go to Venus.

I argued erroneously that "coda_open" needn't be told the flags which
belong with "coda_create".  Here is why I was wrong.

I am using mode bits to explain the story, one should probably read acl
for mode bits (although our VFS layers do honour some mode bits
"automatically"). 

When one creates a new file with mode 444 (read only), the syscall create
apparently must return a file descriptor to a file that is writeable. This
is so because otherwise "tar" cannot unpack archives which contain read
only files (and indeed this is failing on Linux at the moment).  Of
course, opening an existing file with mode bits 0x444 is different: these
should not be writeable.

The only way coda_open is going to know that it is called in the context
of a create is by passing it the create flags (which I had removed from my
kernel code).  This explains which Venus is quite careful about these
flags.

Anyway, the mystery seems to be coming to an end, it's good we hadn't
whacked this out of Venus yet.

(Bob, can you unpack read only archive files on BSD?)

- Peter -
Received on 1998-04-17 17:45:04