Don't panic if renaming a file to itself
Don't try to keep access times, there is no place for them
While being here, fix some minor bugs with VFAT handling
have much in common, there are some differences in the bpb/bootsector that
needed to be handled in the mounting code. The gemdos bpb/bootsector structs
are included for clarification.
<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)
------------------------------------------------------------------------------
ws