Re: Fixed data in FAT file systems

[Andrew Clausen]

Hi Thomas,

Thomas Roelz wrote:
> Recently I tried some resizing of FAT partitions and I have two questions:
> 
> 1. When starting resize with parted (1.2.9) it almost every time
>    complains...
> 
>         Warning: The file \MSDOS.--- is marked as a system file.
>         This means moving it could cause some programs to stop working.
> 
>    Since I also saw complaints about drvspace.bin (and only that) in
>    this way I wonder if M$ is deterministic here. I only know that M$
>    is rather subtle in the placement of the io.sys etc. with respect
>    to bootability. So what does this mean?

I don't know!  I've never been able to break the Windows boot-up
process.  IF the process IS broken, you can always boot off a floppy
and do:

        A:\> sys c:

So, it' probably not a big deal.

BTW, I have removed these warnings for >=1.2.10.  I have never
experienced any problems, or had any bug reports.  But I hear many
complaints from users about having to hit Ignore many times...

> 2. OTOH parted does move data that is classified not movable in defrag
>    (the tiny white squares with a red edge, you know). This is particular
>    unbeautiful if you have created a continuous swap file (win386.swp) of
>    fixed length for performance reasons. After shrinking with parted it
>    may be spread all over the disk. Nevertheless the system is working
>    afterwards even though not very fast. Shouldn't parted leave unmovable
>    data where it is?

Well, yes.

BUT, there is no way to do this.  If you want to shrink or grow the
partition, the data needs to be moved, because the user wants to shrink
or grow the partition!

Also, when resizing FAT file systems, the size of the File Allocation
Tables must change according to a special (i.e. broken) rule (see
libparted/fs_fat/calc.c, fat_calc_sizes()).  When the size of the
FATs must change, all of the clusters must be renumbered.  So, while
the data hasn't been moved, windows will think it has been moved,
because it is in a different cluster number.

I don't really have any ideas on how to solve this...

What do you think?

Andrew Clausen