48 lines
2 KiB
Plaintext
48 lines
2 KiB
Plaintext
|
|
||
|
|
These are a collection of notes that should be updated in the NTFS Design
|
||
|
|
Specification. These do not include many changes which will be obvious
|
||
|
|
from a pass through ntfs.h - which will be a necessary activity for the
|
||
|
|
next spec update.
|
||
|
|
|
||
|
|
File Number changed to File Reference, to denote that its use can
|
||
|
|
become invalid (sequence number incremented).
|
||
|
|
|
||
|
|
The second copy of the log is not needed, but a second copy of the MFT
|
||
|
|
is, which just has the same first three file records: MFT, MFT2 and LOG.
|
||
|
|
|
||
|
|
Add a discussion of the Boot Sector / Boot file, and a figure to show
|
||
|
|
dual boot records and dual MFTs.
|
||
|
|
|
||
|
|
Forget the security on attributes, just use READ_ATTRIBUTE, WRITE_ATTRIBUTE
|
||
|
|
privilege on the file.
|
||
|
|
|
||
|
|
The boot file is strictly a matter between Format, bootstrap, and the Mount
|
||
|
|
code. Where it goes and what its contents are will be system-specific.
|
||
|
|
For NT:
|
||
|
|
|
||
|
|
There will be one boot record at sector 0, and one on the last
|
||
|
|
sector of the volume. Each boot record will contain the cluster size
|
||
|
|
and the starting LCN for the Master File, and the Master File 2.
|
||
|
|
As a suggestion, Format on NT should start the MFT at LCN = 1 on
|
||
|
|
the disk, and MFT2 should start three file record segments before the
|
||
|
|
other boot record. MFT2 contains mirrored copies of the first file
|
||
|
|
record segment for the MFT, MFT2, and the Log file. The boot file
|
||
|
|
on NT just contains these two boot records.
|
||
|
|
|
||
|
|
DOS may choose to actually have a bootstrap following the first
|
||
|
|
boot record in the boot file, and it could just be the first N
|
||
|
|
clusters of the disk.
|
||
|
|
|
||
|
|
"Ideas by Butzi":
|
||
|
|
|
||
|
|
Disks should schedule reads ahead of writes
|
||
|
|
|
||
|
|
Have some way to detect temporary files (file attribute
|
||
|
|
and/or directory attribute), and never write their data
|
||
|
|
(or update valid data length). This would be like putting
|
||
|
|
\temp on the RAM disk on OS/2.
|
||
|
|
|
||
|
|
make writes on close a dynamic option?
|
||
|
|
|
||
|
|
|