Msdos hidden files viewable from linux?

[mdulcey at pryder.pn.com (Mark J. Dulcey)]

On Thu, 26 Oct 1995, Mike Bilow wrote:

> Mark J. Dulcey wrote in a message to Mike Bilow:
> 
>  MJD> Actually, the DOS system files are no longer
>  MJD> position-sensitive in DOS 5  and later.  The only thing
>  MJD> special about IO.SYS and MSDOS.SYS is that  they must be the
>  MJD> first two files listed in the root directory; they can  be
>  MJD> stored anywhere on the disk.
> 
> IO.SYS must start in the first cluster of the data area, but it can be
> fragmented thereafter.

Not true.  I wrote a program to upgrade DOS on PCs (it was a project for 
an add-on capability to a software distribution utility; it never saw the 
light of day because of problems with dealing with memory managers and 
suchlike), so I can assure you that there is no such requirement.  The 
algorithm used by the update program: directly manipulate the root 
directory, creating new directory entries for the two system files (with 
backup names), and clearing the two original directory entries.  Then 
save the two new system files.  (Since DOS always uses the first 
available directory entries, this results in them being the first two 
files in the root directory.)  To reverse the process, delete the two new 
files, and then manipulate the root directory to point the first two 
directory entries back at the old files (and remove the other directory 
entries for them).  Yes, the program also dealt with COMMAND.COM and 
DBLSPACE.BIN, but there was no need for low-level manipulation for them.

> While it is true that restoring in this case would likely result in a bootable
> disk, it is important to note that the files may not be restored to the same
> place they came from.  Also, by "completely empty," there must not be even a
> volume label on the partition before IO.SYS and MSDOS.SYS are restored.

The point about the volume label is well taken.  As I point out above, it 
doesn't actually matter that they're not restored to the same place.

> No one should use a permanent Windows swap file anyway, but there is no point
> to backing up a swap file at all.  Delete it and let Windows create a new one.

Why not?  Although it does cost disk space, the permanent swap file gives 
you substantially increased swap performance, especially if you run DOS 
applications.  If you have a permanent swap file, Windows can 
demand-page DOS applications; if you don't, it has to have the entire app 
in RAM whenever it is scheduled.  (Why, you ask?  DOS isn't reentrant.  
If you're using a temporary swap file, Windows has to use DOS to access 
it, so no swapping can be done while a DOS application is running.  This 
restriction may not apply to Windows for Workgroups 3.11 with 32-bit file 
access, or to Windows 95.)

It's true, of course, that backing up a swap file is a waste of good tape 
and backup time.  Recent DOS and Windows backup programs usually ship 
with *.SWP in their default exclusion list, so they never back up such 
files.