

The File System Paradox (2007) - luu
https://technet.microsoft.com/en-us/magazine/2007.11.windowsconfidential.aspx

======
red_admiral
Back in the days of MS-DOS, I used to wonder why MSDOS.SYS had both the H
(hidden) and S (system) attributes set, whereas COMMAND.COM, without which a
disk wouldn't boot, had none of these.

Only much later did I realise that the S attribute actually meant something
like "the bootloader references this file by disk sector - DEFRAG.EXE, leave
well alone". So MSDOS.SYS/IO.SYS would contain the filesystem driver, and then
load COMMAND.COM "by name".

~~~
oso2k
I don't think that was ever true. DOS 7.x proved this as MSDOS.SYS became a
text file. The DOS boot process always required IO.SYS to load MSDOS.SYS [0].

[0]
[http://www.dewassoc.com/support/msdos/dos_boot_process.htm](http://www.dewassoc.com/support/msdos/dos_boot_process.htm)

~~~
Someone1234
You don't think what was ever true? What you said after doesn't contradict
anything they said.

~~~
oso2k
If you read the link, the file attributes (Hidden and/or System) of place no
bearing on the MBR/Bootloader. Even the OP Article also acknowledged that. You
can also read about this on wikipedia [0]. Bootloaders are essentially JeOSes
[1] (in modern parlance) that can do root directory searches for key boot/OS
files, independent of their file attributes. I've seen custom bootloaders
depend on certain files being in certain locations or having certain names.
Dave Dunfield's [2] "DOS-less" EMBEDPC [3] comes to mind as a bootloader that
supported this.

[0]
[http://en.wikipedia.org/wiki/MSDOS.SYS](http://en.wikipedia.org/wiki/MSDOS.SYS)

[1]
[http://en.wikipedia.org/wiki/Just_enough_operating_system](http://en.wikipedia.org/wiki/Just_enough_operating_system)

[2]
[http://www.classiccmp.org/dunfield/dos/index.htm](http://www.classiccmp.org/dunfield/dos/index.htm)

[3]
[http://www.classiccmp.org/dunfield/dos/embedpc.zip](http://www.classiccmp.org/dunfield/dos/embedpc.zip)

~~~
mapgrep
OP was saying (roughly) that the file attributes were used by, for example,
DEFRAG.EXE to avoid having files like MSDOS.sys re-arranged ("defragmented")
on disk because they need to be in certain locations the bootloader expects.

That's fully compatible with what you're saying. Yes, you need those flags to
keep boot-up working properly and, yes, the bootloader ignores the flags.

~~~
oso2k
The files only need to be in certain logical locations (like the root of the
drive), not physical locations. Fragmentation is not an issue either. See what
FreeDOS say about this [0].

[0]
[http://help.fdos.org/en/hhstndrd/base/attrib.htm](http://help.fdos.org/en/hhstndrd/base/attrib.htm)

------
turrini
About TempleOS, Terry Davis wrote:

TerryADavis 30 minutes ago [dead]

My bootloader uses a fixed LBA block address. When I install Kernel.BIN onto
the disk, I patch the bootloader with the LBA of Kernel.BIN. It is stored
contiguously. My bootloader knows nothing about filesystems.

~~~
Someone1234
They appear to be banned. All of their comments are dead even the non-
controversial ones like this. Too bad.

Why don't they let up/down votes sort out the quality of comments and stop
banning non-spammers. Seems heavy handed.

~~~
qbrass
Just let people upvote banned users comments out of oblivion if they think
it's worth seeing.

------
jvert
Raymond is almost always 100% right, but in this case he (or Adrian) is a bit
off. The mini filesystems in NTLDR can absolutely traverse subdirectories.
After all, things like the kernel are found in places like
C:\WINDOWS\SYSTEM32\NTOSKRNL.EXE and NTLDR has to load that. There is a
"nanofilesystem" in the boot sector(s) which only knows how to load C:\NTLDR,
but NTLDR could easily restore a hibernation file that was in a subdirectory.

The real reason these are in the root is because There Can Be Only One. You
can have multiple versions of windows in different directories on the same
drive, but only one NTLDR or BOOT.INI or HIBERFIL.SYS. If you put them in
subdirectories, then you can now have more than one and NTLDR doesn't know
which one to use.

And as somebody else pointed out, this all got rewritten after Windows XP.

------
userbinator
Of course, now that there is EFI, the "BIOS" contains its own rather fully-
featured FAT filesystem driver, so it could theoretically boot and resume from
hibernate without requiring the files be in the root.

I don't think that's a better way of doing it. The "dumb and simple" BIOS way,
where all it did was load the first sector of the boot device into memory and
jump to it, was far easier to understand and debug.

~~~
andreiw
(U)EFI has a very open architecture. MS could well write an NTFS driver and
register it with the firmware to be loaded prior to handing off to the NT boot
manager.

These sort of things tend to go against the grain of platform portability,
though, even though pretty much the only platforms Windows appears to support
these days are (or have been) consolidating around UEFI and ACPI.

------
tbrock
Cool explanation but I wonder why other operating systems don't have the same
restriction. On OSX, for example, it used to be here:
/private/var/vm/sleepimage

I suppose they have a clever boot loader with advanced drivers?

~~~
Someone
I don't know whether they do, but a clever alternative is to have a stupid
boot loader. You don't need to know how to traverse directories, you just need
to know what blocks on disk to read. So, just write the number of the first
block of the hibernation file to a known location (say in the first disk
block) and you are all set.

Well, all: the file may be fragmented. Just store information about where to
find all the blocks in the first block of the hibernation file (alternative
view of this is that you have a very simple alternative file system on the
disk that stores only one file (or a few, if you also want the ability to find
the kernel for a cold boot)

Risk with such approaches is that they may not survive defragmentation of the
drive. That's a minor risk for a hibernation file, I would say.

~~~
wfunction
It's not minor. It's a freaking pain in the rear to have to fix this every
time you defragment or move/resize a partition.

~~~
Someone
If your defragmenter knows about the hibernation system, it will update the
'pointer' to the hibernation file.

Also, you can only hibernate an OS that knows about hibernation. Such an OS
would be foolish if it wouldn't write the current location of the hibernation
file whenever it went into hibernation.

So, this only is a problem if you hibernate your system, defragment its disk
on another system using a defragmenter that doesn't know about hibernation
files, and then try to wake up from hibernation. That might happen to people
using an old version of a defragmenter, but I doubt it will happen often.

------
h43k3r
Its always fun to understand how such basic things are done when you don't
have an OS loaded.

A very good article on how does your computer boot up.

[http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-
HOW...](http://www.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-
HOWTO/bootup.html)

