PR4394: be more consistent with other MSDOSFS_DEBUG messages
PR4395: fix generation numbers as in the PR, and fix short name for e.g. x.aaaa
PR4396: easier fix then given in the PR
All PRs by Rick Byers. Thanks Rick for pointing these out
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
struct member cn_nameptr 'const', since they should never be used to
modify the path name. (Only the pathname buffer, cn_pnbuf, should be
modified.) Propagate the const poisoning to code that uses the namei
and componentname structs.
<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)
------------------------------------------------------------------------------
