how much of the file to pass in the exec package, but i think the
solution to that will be to pass e.g. a disk block's worth, or whatever;
if exec handlers really need more, they've got the damned vnode.
if it doesn't there's a problem in the kernel, because a program
with no exec commands run will have no address space except the stack,
and i don't think it's valid to have a "run from stack only" exec type,
so panic. if need for that case comes up later, it can be changed...
<polk@bsdi.com>. His notes are as follows:
------------------------------------------------------------------------------
July 22, 1993
- Changed name of entire package from PCFS to MSDOSFS
- Fixed bugs:
root directory size in clusters instead of bytes
growing directory didn't update in-core size
link, symlink, mknod didn't free locked parent (deadlock)
lookup returned real error on create and rename instead of EJUSTRETURN
rename changed `.' entry in child instead of name entry in parent
rename removed `.' entry in child instead of removing entry in
parent when moving a directory from one dir to another
createde() left new node locked when write of parent failed (deadlock)
removede() decremented refcount even on error (rmdir's which failed
due to write errors left in-core cache entries inconsistent)
changed validation for filesystem to not check for the boot signature
since some disks (e.g., mtools) aren't bootable
directories are always show current time as modify time
(needed for NFS export since DOS never updates dir mod times --
ctime is true create time).
- Added support for cookies changes to the readdir() vnode
interface (#ifdef __bsdi__)
- Punted on the whole problem of inode generation numbers. This means
that there's a chance of using a stale file handle to access a new
file, but it doesn't appear to be the common case, and I don't see
how to generate reasonable generation numbers without changing something
on the disk (which is the way the SVR4 filesystem survival kit guys
did it). I don't think it would be very safe to change the on-disk
format.
Jeff Polk (polk@BSDI.COM)
------------------------------------------------------------------------------
