Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.lang.asm > #6613 > unrolled thread

The Virtual Partition - say goodbye to FAT12

Back to article view | Back to alt.lang.asm

Contents

  The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-03-31 17:51 -0400
    Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-03-31 20:48 -0500
      Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-01 06:50 -0400
        Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-04-01 11:06 -0500
          Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-01 13:45 -0400
            Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-04-01 17:06 -0500
              Re: The Virtual Partition - say goodbye to FAT12 James Harris <james.harris.1@gmail.com> - 2016-04-01 23:16 +0100
                Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-04-01 17:29 -0500
                  Re: The Virtual Partition - say goodbye to FAT12 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-01 20:24 -0400
                    Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-04-02 00:10 -0500
                      Re: The Virtual Partition - say goodbye to FAT12 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-02 12:03 -0400
                        Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 20:19 -0400
                      Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 20:08 -0400
                    Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 20:02 -0400
                  Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 19:55 -0400
                Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 19:30 -0400
              Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 18:55 -0400
                Re: The Virtual Partition - say goodbye to FAT12 Robert Wessel <robertwessel2@yahoo.com> - 2016-04-04 00:40 -0500
    Re: The Virtual Partition - say goodbye to FAT12 "wolfgang kern" <nowhere@never.at> - 2016-04-01 09:20 +0200
      Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-01 07:01 -0400
        Re: The Virtual Partition - say goodbye to FAT12 "wolfgang kern" <nowhere@never.at> - 2016-04-04 10:42 +0200
          Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-05 15:58 -0400
            Re: The Virtual Partition - say goodbye to FAT12 "wolfgang kern" <nowhere@never.at> - 2016-04-05 22:19 +0200
              Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-05 18:24 -0400
    Re: The Virtual Partition - say goodbye to FAT12 James Harris <james.harris.1@gmail.com> - 2016-04-01 09:55 +0100
      Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-01 07:11 -0400
    Re: The Virtual Partition - say goodbye to FAT12 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-04-01 20:24 -0400
      Re: The Virtual Partition - say goodbye to FAT12 "Mike Gonta" <mikegonta@gmail.com> - 2016-04-02 21:30 -0400

Page 1 of 2  [1] 2  Next page →

#6613 — The Virtual Partition - say goodbye to FAT12

http://forum.osdev.org/viewtopic.php?f=1&t=30254


Mike Gonta
look and see - many look but few see

http://mikegonta.com

[toc] | [next] | [standalone]

#6615

On Thu, 31 Mar 2016 17:51:44 -0400, "Mike Gonta" <mikegonta@gmail.com>
wrote:

>http://forum.osdev.org/viewtopic.php?f=1&t=30254


What's the point?  No standard OS will respect the limits of this
modified FAT32 FS, so there's no advantage there, and reading the root
directory (and let's not forget that there is no requirement that a
FAT12/16 root directory be 9 sectors) looking for a couple of boot
files and then loading those is hardly that complex.  And if you need
more code than you can fit into just the boot sector, all three FAT
formats provide reserved areas in fixed locations that you can use.

[toc] | [prev] | [next] | [standalone]

#6618

"Robert Wessel" wrote:
> "Mike Gonta" wrote:
>
>> http://forum.osdev.org/viewtopic.php?f=1&t=30254
>
Hi Robert,

> What's the point?

The Virtual Partition enables a simple system FAT32 file
system driver to be as as simple as a FAT12 driver.

> No standard OS will respect the limits of this
> modified FAT32 FS, so there's no advantage there, and ...

There are _absolutely_ no modifications to the file system.
The standard OS's format FAT32 one way, this is just an
alternate way and it is fully compatible with the MS FAT32
file system specification.
It works perfectly for me on Windows. It can be
"checked for errors" and even defragmented - no problem.
A much better statement would be that you tried it on
Windows or Linux or Xyz and it didn't work.

There's no executable involved, you simple assemble the
binary (it's in GCC but easily converted to GAS/NASM/FASM
etc.) and transfer it to a flash drive.

The Virtual Partition is completely virtual. There is no
actual partition, even the flash drive is not partitioned
and will work even if it is.

> ... reading the root directory (and let's not forget that
> there is no requirement that a FAT12/16 root directory be
> 9 sectors) looking for a couple of boot files and then
> loading those is hardly that complex.

I agree, but you are describing a boot sector boot loader
that only reads and loads a named file; not a full FAT32
file system driver which is much more complex than a
FAT12/16 driver. The MS FAT32 boot sector boot loader is
actually 2 sectors (the second is loaded by the first)
as compared to the single sector FAT12/16 boot sector
boot loader.

> And if you need more code than you can fit into just the
> boot sector, all three FAT formats provide reserved
> areas in fixed locations that you can use.

With the Virtual Partition the FAT32 boot sector boot loader
that reads and loads a named file from the root directory
is only one sector. This is because it is exactly the same
as a FAT12/16 boot sector (the only technical difference
being the same difference between FAT12 and FAT16 - namely
the size of the FAT table entry: 12 vs. 16. vs 32).


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6621

On Fri, 1 Apr 2016 06:50:41 -0400, "Mike Gonta" <mikegonta@gmail.com>
wrote:

>"Robert Wessel" wrote:
>> "Mike Gonta" wrote:
>>
>>> http://forum.osdev.org/viewtopic.php?f=1&t=30254
>>
>Hi Robert,
>
>> What's the point?
>
>The Virtual Partition enables a simple system FAT32 file
>system driver to be as as simple as a FAT12 driver.
>
>> No standard OS will respect the limits of this
>> modified FAT32 FS, so there's no advantage there, and ...
>
>There are _absolutely_ no modifications to the file system.
>The standard OS's format FAT32 one way, this is just an
>alternate way and it is fully compatible with the MS FAT32
>file system specification.
>It works perfectly for me on Windows. It can be
>"checked for errors" and even defragmented - no problem.
>A much better statement would be that you tried it on
>Windows or Linux or Xyz and it didn't work.
>
>There's no executable involved, you simple assemble the
>binary (it's in GCC but easily converted to GAS/NASM/FASM
>etc.) and transfer it to a flash drive.
>
>The Virtual Partition is completely virtual. There is no
>actual partition, even the flash drive is not partitioned
>and will work even if it is.
>
>> ... reading the root directory (and let's not forget that
>> there is no requirement that a FAT12/16 root directory be
>> 9 sectors) looking for a couple of boot files and then
>> loading those is hardly that complex.
>
>I agree, but you are describing a boot sector boot loader
>that only reads and loads a named file; not a full FAT32
>file system driver which is much more complex than a
>FAT12/16 driver. The MS FAT32 boot sector boot loader is
>actually 2 sectors (the second is loaded by the first)
>as compared to the single sector FAT12/16 boot sector
>boot loader.
>
>> And if you need more code than you can fit into just the
>> boot sector, all three FAT formats provide reserved
>> areas in fixed locations that you can use.
>
>With the Virtual Partition the FAT32 boot sector boot loader
>that reads and loads a named file from the root directory
>is only one sector. This is because it is exactly the same
>as a FAT12/16 boot sector (the only technical difference
>being the same difference between FAT12 and FAT16 - namely
>the size of the FAT table entry: 12 vs. 16. vs 32).


I don't understand - is this not the beginning of the "normal" FAT32
partition, or is it someplace else?  If it's someplace else, how does
the BIOS get to the partition to boot it?

If it is the beginning of the "normal" FAT32 partition, what's to
prevent the defrag program from moving the root directory, or from the
OS from simply extending the root directory if more than ~255 files
(less if there are LFNs, more if clusters are bigger than 512 bytes)
get written to the root directory?

And again, why is it a problem if the boot code is two sectors?  Or
three, or four?

[toc] | [prev] | [next] | [standalone]

#6622

Robert Wessel" wrote:

> I don't understand - is this not the beginning of the
> "normal" FAT32 partition, or is it someplace else?
>  If it's someplace else, how does the BIOS get to the
> partition to boot it?

There are no partitions.

> If it is the beginning of the "normal" FAT32 partition,

Volume.

> what's to prevent the defrag program from moving the
> root directory,

I didn't know that defrag could/would do that.
This is only for simple hobby OS's, etc - just don't defrag.
Out of curiosity, (I always look and see) I wrote many
files to the drive and confirmed in HxD that the root
directory 512 byte clusters (the clusters in the
Virtual Partition can be any size) were severely fragmented
- each 16 entry root cluster was separated on drive by it's
16 - 512 byte files and so on and so on. The defrag analysis
showed 0 fragmentation, I defragged anyways and absolutely
nothing changed.

> or from the OS from simply extending the root directory
> if more than ~255 files (less if there are LFNs, more
> if clusters are bigger than 512 bytes) get written to
> the root directory?

There's nothing stopping it, nor should there be. The
Virtual Partition will still work.

> And again, why is it a problem if the boot code is two
> sectors?  Or three, or four?

It's _absolutely_ no problem at all. The Virtual Partition
changes none of that.

1.  There are no partitions.
2.  The Virtual Partition is _virtual_ - the standard OS
    knows absolutely nothing about it - and it doesn't need
    to know.
3.  Only the simple system FAT32 driver knows about it.
4.  The simple system FAT32 driver is exactly the same as
    the FAT12 driver - the only difference is FAT32.
5.  The simple driver can only see and access the files in
    the first 2048 clusters at the beginning of the volume.
    This is what makes it as simple as FAT12.
6.  The Virtual Partition is aid to the small system
    developer (hobby OS) and absolutely free of cost,
    patents or copyright.
7.  The Virtual Partition in no way hampers the development
    of a full FAT32 driver.
8.  The rest of the world has said goodbye to FAT12 and
    FAT16 a long time ago. Windows won't format anything
    FAT12. The last time I looked a 32GB flash drive was
    selling for 10 dollars, if you're lucky you can still
    get a 8GB or 16GB drive. 2GB is the maximum size for
    FAT16.
9.  Say goodbye to FAT12 and FAT16. Hello simple FAT32.

Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6623

On Fri, 1 Apr 2016 13:45:51 -0400, "Mike Gonta" <mikegonta@gmail.com>
wrote:

>Robert Wessel" wrote:
>
>> I don't understand - is this not the beginning of the
>> "normal" FAT32 partition, or is it someplace else?
>>  If it's someplace else, how does the BIOS get to the
>> partition to boot it?
>
>There are no partitions.
>
>> If it is the beginning of the "normal" FAT32 partition,
>
>Volume.
>
>> what's to prevent the defrag program from moving the
>> root directory,
>
>I didn't know that defrag could/would do that.
>This is only for simple hobby OS's, etc - just don't defrag.


Seems like a really user unfriendly policy: Don't do something
normally perfectly legal and often used.


>Out of curiosity, (I always look and see) I wrote many
>files to the drive and confirmed in HxD that the root
>directory 512 byte clusters (the clusters in the
>Virtual Partition can be any size) were severely fragmented
>- each 16 entry root cluster was separated on drive by it's
>16 - 512 byte files and so on and so on. The defrag analysis
>showed 0 fragmentation, I defragged anyways and absolutely
>nothing changed.


Windows' built-in defrag is pretty basic.  Some of the better ones
have done drastically more work.  In any event it's up to \you to
prove it *won't* happen for some reason.


>> or from the OS from simply extending the root directory
>> if more than ~255 files (less if there are LFNs, more
>> if clusters are bigger than 512 bytes) get written to
>> the root directory?
>
>There's nothing stopping it, nor should there be. The
>Virtual Partition will still work.
>
>> And again, why is it a problem if the boot code is two
>> sectors?  Or three, or four?
>
>It's _absolutely_ no problem at all. The Virtual Partition
>changes none of that.
>
>1.  There are no partitions.
>2.  The Virtual Partition is _virtual_ - the standard OS
>    knows absolutely nothing about it - and it doesn't need
>    to know.


I still don't get it.  Does the "standard OS" see this "virtual FAT32"
volume or not?  Just part of it as a (subset) of a "real" FAT32
volume?  If so, how are you preventing the "standard OS" from doing
something that messes up the subset your device needs to see?


>3.  Only the simple system FAT32 driver knows about it.
>4.  The simple system FAT32 driver is exactly the same as
>    the FAT12 driver - the only difference is FAT32.
>5.  The simple driver can only see and access the files in
>    the first 2048 clusters at the beginning of the volume.
>    This is what makes it as simple as FAT12.


How do you ensure that the files you want are in either the beginning
of the root directory, or in the first 2048 clusters of the volume?


>6.  The Virtual Partition is aid to the small system
>    developer (hobby OS) and absolutely free of cost,
>    patents or copyright.
>7.  The Virtual Partition in no way hampers the development
>    of a full FAT32 driver.


That's fine, but since you're talking about a tiny amount of
additional code, why should anyone care?


>8.  The rest of the world has said goodbye to FAT12 and
>    FAT16 a long time ago. Windows won't format anything
>    FAT12.


Sure it will.  Just format a partition too small to put a FAT16 volume
on it.  Or use the /A: parameter to force big enough cluster sizes
that the total number of clusters drop below 4085.  Or attach a floppy
drive to your computer.  There are obviously upper limits to the size
of a FAT12 or FAT16 volume (~131MiB and ~1.1GiB) based on the maximum
possible cluster size (32KB).


> The last time I looked a 32GB flash drive was
>    selling for 10 dollars, if you're lucky you can still
>    get a 8GB or 16GB drive. 2GB is the maximum size for
>    FAT16.


How is that relevant?


>9.  Say goodbye to FAT12 and FAT16. Hello simple FAT32.


Hello FAT32 that only works some of the time?  I'd like to avoid
making that acquaintance.  Why not just do it right in the first
place?  Now there are certainly some simplifications you can make to
full FAT32 support, that don't break the volume for other use.  You
could avoid supporting LFNs, for example (although LFNs are not
actually tied to FAT32), or you could just enable your device to read
the root directory.  OTOH, if you don't care about other systems
accessing the volume, do whatever makes sense for your device, just
don't pretend it's FAT32.

[toc] | [prev] | [next] | [standalone]

#6624

On 01/04/2016 23:06, Robert Wessel wrote:

...

> I still don't get it.  Does the "standard OS" see this "virtual FAT32"
> volume or not?  Just part of it as a (subset) of a "real" FAT32
> volume?

I am not sure I get it either but Mike can correct me. AIUI he has 
worked out a way to format a FAT32 volume which makes the volume as 
simple as FAT12 to access. That includes things like putting the root 
directory a the start. FAT32 allows it to go anywhere.

In other words, it is a completely legitimate way to lay out a FAT32 
volume (so it is a normal FAT32 volume) but it imposes some restrictions 
and thereby makes processing the volume easier (i.e. in a lesser amount 
of code).

 > If so, how are you preventing the "standard OS" from doing
 > something that messes up the subset your device needs to see?

I think normal OS accesses don't modify any of Mike's key changes.

I'll be interested to hear if my understanding is right. I think, in 
particular, there's some part of it that I have missed.

-- 
James

[toc] | [prev] | [next] | [standalone]

#6625

On Fri, 1 Apr 2016 23:16:57 +0100, James Harris
<james.harris.1@gmail.com> wrote:

>On 01/04/2016 23:06, Robert Wessel wrote:
>
>...
>
>> I still don't get it.  Does the "standard OS" see this "virtual FAT32"
>> volume or not?  Just part of it as a (subset) of a "real" FAT32
>> volume?
>
>I am not sure I get it either but Mike can correct me. AIUI he has 
>worked out a way to format a FAT32 volume which makes the volume as 
>simple as FAT12 to access. That includes things like putting the root 
>directory a the start. FAT32 allows it to go anywhere.


That's my understanding as well.


>In other words, it is a completely legitimate way to lay out a FAT32 
>volume (so it is a normal FAT32 volume) but it imposes some restrictions 
>and thereby makes processing the volume easier (i.e. in a lesser amount 
>of code).


Fully agree.  Although IMO the mount of additional code needed to do
this properly is very small.


> > If so, how are you preventing the "standard OS" from doing
> > something that messes up the subset your device needs to see?
>
>I think normal OS accesses don't modify any of Mike's key changes.
>
>I'll be interested to hear if my understanding is right. I think, in 
>particular, there's some part of it that I have missed.


What's to prevent a defrag from moving the root directory?  What's to
prevent the OS from extending the root directory, and then putting the
directory entry for a file you're interested in after the 16th cluster
of the root directory file?  What's to prevent the OS from putting a
file (in the root directory) into a cluster past #2048 on the
partition?  Or extending a file to a cluster>2048?  Or having defrag
move it there?

Now if the "standard OS" is not allowed to modify the volume (say this
is intended to move data from some device to (say) a Windows
workstation), the problems are reduced (there's not a good way to
enforce such a read-only status).

[toc] | [prev] | [next] | [standalone]

#6627

On Fri, 01 Apr 2016 17:29:49 -0500
Robert Wessel <robertwessel2@yahoo.com> wrote:

> What's to prevent a defrag from moving the root directory?  What's to
> prevent the OS from extending the root directory, and then putting the
> directory entry for a file you're interested in after the 16th cluster
> of the root directory file?  What's to prevent the OS from putting a
> file (in the root directory) into a cluster past #2048 on the
> partition?  Or extending a file to a cluster>2048?  Or having defrag
> move it there?

This seems to be intended more for ease of filesystem setup and
access for primitive OSes, instead of 100% compatibility with FAT32
capable OSes like Linux or Windows.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#6628

On Fri, 1 Apr 2016 20:24:49 -0400, Rod Pemberton
<NoHaveNotOne@bcczxcfre.cmm> wrote:

>On Fri, 01 Apr 2016 17:29:49 -0500
>Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>> What's to prevent a defrag from moving the root directory?  What's to
>> prevent the OS from extending the root directory, and then putting the
>> directory entry for a file you're interested in after the 16th cluster
>> of the root directory file?  What's to prevent the OS from putting a
>> file (in the root directory) into a cluster past #2048 on the
>> partition?  Or extending a file to a cluster>2048?  Or having defrag
>> move it there?
>
>This seems to be intended more for ease of filesystem setup and
>access for primitive OSes, instead of 100% compatibility with FAT32
>capable OSes like Linux or Windows.


What's the point of FAT32 compatibility if the resulting volume cannot
be safely accessed by Windows?  I assume you'd want a FAT32 volume so
that you *could* mount the volume on a Windows or Linux PC, and fiddle
with the contents.  Perhaps edit a configuration file, copy some
output file from the device off the volume, etc.

[toc] | [prev] | [next] | [standalone]

#6629

On Sat, 02 Apr 2016 00:10:07 -0500
Robert Wessel <robertwessel2@yahoo.com> wrote:

> On Fri, 1 Apr 2016 20:24:49 -0400, Rod Pemberton
> <NoHaveNotOne@bcczxcfre.cmm> wrote:
> >On Fri, 01 Apr 2016 17:29:49 -0500
> >Robert Wessel <robertwessel2@yahoo.com> wrote:

> >> What's to prevent a defrag from moving the root directory?  What's
> >> to prevent the OS from extending the root directory, and then
> >> putting the directory entry for a file you're interested in after
> >> the 16th cluster of the root directory file?  What's to prevent
> >> the OS from putting a file (in the root directory) into a cluster
> >> past #2048 on the partition?  Or extending a file to a
> >> cluster>2048?  Or having defrag move it there?  
> >
> >This seems to be intended more for ease of filesystem setup and
> >access for primitive OSes, instead of 100% compatibility with FAT32
> >capable OSes like Linux or Windows.  
> 
> What's the point of FAT32 compatibility if the resulting volume cannot
> be safely accessed by Windows?  I assume you'd want a FAT32 volume so
> that you *could* mount the volume on a Windows or Linux PC, and fiddle
> with the contents.  Perhaps edit a configuration file, copy some
> output file from the device off the volume, etc.

At this point, I'm thinking it's mainly about an easy to implement
boot driver combined with a larger filesystem size, but Mike would
need to clarify.  The fact that it can be accessed as FAT32 means
you don't need extra utilities to create the image.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#6635

"Rod Pemberton" wrote:

< as the world turns >

> At this point, I'm thinking it's mainly about an easy
> to implement boot driver combined with a larger
> filesystem size, but Mike would need to clarify.

Hi Rod,

The clarification is coming.

> The fact that it can be accessed as FAT32 means you
> don't need extra utilities to create the image.

Exactly, if Linux or Windows won't do it, simply do it
yourself.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6634

"Robert Wessel" wrote:
> "Rod Pemberton" wrote:
>>"Robert Wessel" wrote:
>>
>>> What's to prevent a defrag from moving the root
>>> directory?  What's to prevent the OS from extending
>>> the root directory, and then putting the directory
>>> entry for a file you're interested in after the 16th
>>> cluster of the root directory file?  What's to prevent
>>> the OS from putting a file (in the root directory)
>>> into a cluster past #2048 on the partition?  Or
>>> extending a file to a cluster>2048?  Or having defrag
>>> move it there?
>>
>>This seems to be intended more for ease of filesystem
>> setup and access for primitive OSes, instead of 100%
>> compatibility with FAT32 capable OSes like Linux or
>> Windows.
>
> What's the point of FAT32 compatibility if the resulting
> volume cannot be safely accessed by Windows?  I assume
> you'd want a FAT32 volume so that you *could* mount the
> volume on a Windows or Linux PC, and fiddle with the
> contents.  Perhaps edit a configuration file, copy some
> output file from the device off the volume, etc.

Hi Robert,

It can and you could. Please see my previous posts.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta 

[toc] | [prev] | [next] | [standalone]

#6633

"Rod Pemberton" wrote:
> "Robert Wessel" wrote:
>
>> What's to prevent a defrag from moving the root
>> directory?  What's to prevent the OS from extending the
>> root directory, and then putting the >> directory entry
>> for a file you're interested in after the 16th cluster
>> of the root directory file?  What's to prevent the OS
>> from putting a file (in the root directory) into a
>> cluster past #2048 on the partition?  Or extending a
>> file to a cluster>2048?  Or having defrag move it there?
>
> This seems to be intended more for ease of filesystem
> setup and access for primitive OSes,

Hi Rod,

Your're absolutely right.

> instead of 100% compatibility with FAT32 capable OSes
> like Linux or Windows.

But, the Virtual Partition is fully 100% compatible with the
MS FAT32 specification (including Linux and Windows).


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6632

"Robert Wessel" wrote:
> "James Harris" wrote:
>> "Robert Wessel" wrote:

>>> I still don't get it.  Does the "standard OS" see this
>>> "virtual FAT32" volume or not?  Just part of it as a
>>> (subset) of a "real" FAT32 volume?

>>I am not sure I get it either but Mike can correct me.
>>AIUI he has worked out a way to format a FAT32 volume
>>which makes the volume as simple as FAT12 to access.
>>That includes things like putting the root directory a
>>the start. FAT32 allows it to go anywhere.

> That's my understanding as well.

>>In other words, it is a completely legitimate way to
>>lay out a FAT32 volume (so it is a normal FAT32 volume)
>>but it imposes some restrictions and thereby makes
>>processing the volume easier (i.e. in a lesser amount
>>of code).

> Fully agree.  Although IMO the mount of additional code
> needed to do this properly is very small.

>> > If so, how are you preventing the "standard OS" from
>> > doing something that messes up the subset your device
>> > needs to see?
>>
>>I think normal OS accesses don't modify any of Mike's key
>>changes.
>>
>>I'll be interested to hear if my understanding is right.
>>I think, in particular, there's some part of it that I
>>have missed.

> What's to prevent a defrag from moving the root
> directory?  What's to prevent the OS from extending the
> root directory, and then putting the directory entry for
> a file you're interested in after the 16th cluster of
> the root directory file?  What's to prevent the OS from
> putting a file (in the root directory) into a cluster
> past #2048 on the partition?  Or extending a file to a
> cluster>2048?  Or having defrag move it there?

_Absolutely nothing_ that the end user does not initiate.

> Now if the "standard OS" is not allowed to modify the
> volume (say this is intended to move data from some
> device to (say) a Windows workstation), the problems
> are reduced (there's not a good way to enforce such a
> read-only status).

Keep in mind that the Virtual Partition is designed to
be a simple system. Never the less and not withstanding,
the end user (or should I say - the beginner) is in full
control simply by following the protocol. See my previous
post to James.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6631

"James Harris" wrote:
> "Robert Wessel" wrote:

>> I still don't get it.  Does the "standard OS" see this
>> "virtual FAT32" volume or not?  Just part of it as a
>> (subset) of a "real" FAT32 volume?
>
> I am not sure I get it either but Mike can correct me.
> AIUI he has worked out a way to format a FAT32 volume
> which makes the volume as simple as FAT12 to access.

Makes the Virtual Partition (at the beginning of the
volume) as "simple as FAT12 to access."

> That includes things like putting the root directory
> a the start. FAT32 allows it to go anywhere.

In actual use (unless going to extreme cases it will
never move). In addition to defragging, ideally (and even
Windows will do so) the most used programs are moved to
the front. The chances of the root directory (the most
important "file" on the volume) being move outside the
Virtual Partition is slim to nil. As I explained to Robert
in a previous post that there is no requirement for
anything being located at a "fixed" location. The
Virtual Partition is _fully_ compatible with the
specification.

> In other words, it is a completely legitimate way to lay
> out a FAT32 volume (so it is a normal FAT32 volume) but
> it imposes some restrictions and thereby makes processing
t> he volume easier (i.e. in a lesser amount of code).

In actual words, it is only by following the
Virtual Partition protocol (which the simple system does
voluntarily - to keep things simple) that a simple
restriction is imposed. In other words, by following the
protocol only those fils withing the Virtual Partition
are accessible.

> > If so, how are you preventing the "standard OS" from
> > doing something that messes up the subset your device
> > needs to see?
>
> I think normal OS accesses don't modify any of Mike's
> key changes. I'll be interested to hear if my
> understanding is right. I think, in particular, there's
> some part of it that I have missed.

The rest should become crystal clear as soon as I explain
the Virtual Partition protocol (up till now it's been
mostly the specification). I'm currently working on the
first draft of the AOD Virtual Partition Specification
and Protocol. That's right, AOD. Every one here who has
critiqued it will be given credit (I appreciate the
feedback), unless of course they don't wish to be
associated with it (you don't have to decide now, wait
until you get the full story). This way it will be a
community effort.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6630

"Robert Wessel" wrote:
> "Mike Gonta" wrote:

>>I didn't know that defrag could/would do that.
>>This is only for simple hobby OS's, etc - just don't
>>defrag.
>
> Seems like a really user unfriendly policy: Don't do
> something normally perfectly legal and often used.
> Windows' built-in defrag is pretty basic.  Some of the
> better ones have done drastically more work.  In any
> event it's up to \you to prove it *won't* happen for some
> reason.

Fact is, it absolutely doesn't matter even if it did.
Remember, the reason I am pre-allocating enough root
directory cluster to provide at least 16 sectors is so that
they are contiguous, defragging will only result in more
contiguous sectors. The Virtual Partition protocol will only
permit access to those first 16 anyways, so there will be
no benefit gained (or loosed) by doing so. The business of
the "fixed" location was only as analogy to the subset of
the simple system FAT12 driver. To keep thing simple that
driver "assumes" that the fat and root are located at a
"fixed" locations and for simplicity "hard codes" these
values in the code. But of course, in the FAT file system
(even a 1.44MB floppy disk) any number of Reserved Sectors
are permitted. Best programming practices dictate the the
values should be calculated using the BPB. For an example
of this check out the difference between the 16 bit real
mode MikeOS http://mikeos.sourceforge.net/ and the 32 bit
protected mode MikeOS FAT(ter)12
https://github.com/mikegonta/MikeOS32
Other than the fact that the latter is a PM32 translation
of the former, the main difference is that I removed all
the "hard coding" and thereby lifted the floppy disk
restriction and "promoted" it to actual FAT12 (including
hard drives).

> I still don't get it.  Does the "standard OS" see this
> "virtual FAT32"volume or not? Just part of it as a
> (subset) of a "real" FAT32 volume?

There is nothing "virtual" or "unreal" about the FAT32
volume (only the Virtual Partition is virtual). There is
_absolutely_ no modifications to the FAT32 volume. The
Virtual Partition is only different from the standard
FAT32 volume in the pre-allocation of the root directory
clusters. The FAT32 root directory is like the
sub directories which are like files. There is nothing in
the specification that says you can not pre-allocate a
file.

> If so, how are you preventing the "standard OS" from
> doing something that messes up the subset your device
> needs to see?

The Virtual Partition is 100% compatible with the
specification. Short of hacking, stupidity and ignorance
there is no way to "mess it up".

>>3.  Only the simple system FAT32 driver knows about it.
>>4.  The simple system FAT32 driver is exactly the same as
>>    the FAT12 driver - the only difference is FAT32.
>>5.  The simple driver can only see and access the files
>>    in  the first 2048 clusters at the beginning of the
>>    volume.
>>    This is what makes it as simple as FAT12.

> How do you ensure that the files you want are in either
> the beginning of the root directory, or in the first
> 2048 clusters of the volume?

All files written to a FAT32 volume appear on the drive in
the order they are written starting at the beginning of the
data and root directory. If you write too many file and
fill up the Virtual Partition then, (just like a floppy
disk) you are SOL, sorry no more room. By following the
Virtual Partition protocol the simple system _can not_
read or write files outside of the Virtual Partition.

>>6.  The Virtual Partition is aid to the small system
>>    developer (hobby OS) and absolutely free of cost,
>>    patents or copyright.
>>7.  The Virtual Partition in no way hampers the
>>    development of a full FAT32 driver.

> That's fine, but since you're talking about a tiny amount
> of additional code, why should anyone care?

A full blown FAT32 driver is anything but tiny (or simple).
The simple system FAT32 driver that I've written (based on
the Virtual Partition protocol) on the other hand is tiny
(and simple).

>>8.  The rest of the world has said goodbye to FAT12 and
>>    FAT16 a long time ago. Windows won't format anything
>>    FAT12.

> Sure it will.  Just format a partition too small to put a
> FAT16 volume on it.  Or use the /A: parameter to force
> big enough cluster sizes that the total number of
> clusters drop below 4085.  Or attach a floppy drive to
> your computer.  There are obviously upper limits to the
> size of a FAT12 or FAT16 volume (~131MiB and ~1.1GiB)
> based on the maximum possible cluster size (32KB).

I didn't mean that you can't do it, I meant that you can't
do it. Even I use an old computer that has a floppy disk
drive. (I disconnected the cable a long time ago because
of the "clicking and grinding" when the PC starts up. Who's
going to bother doing that when ...

>> The last time I looked a 32GB flash drive was selling
>> for 10 dollars, if you're lucky you can still get a 8GB
>> or 16GB drive. 2GB is the maximum size for FAT16.

> How is that relevant?

This explains that.

>>9.  Say goodbye to FAT12 and FAT16. Hello simple FAT32.

> Hello FAT32 that only works some of the time?  I'd like
> to avoid making that acquaintance.

Only because I didn't explain it properly. It does work
fine (and all of the time).

>  Why not just do it right in the first place?

It's not an issue of right or wrong, simply a matter of
learning to walk before running.

> Now there are certainly some simplifications you can make
> to full FAT32 support, that don't break the volume for
> other use.

As I explained _nothing_ is broken.

> You could avoid supporting LFNs, for example (although
> LFNs are not actually tied to FAT32),

I do.

> or you could just enable your device to read the root
> directory.

I do that to.

> OTOH, if you don't care about other systems accessing
> the volume, do whatever makes sense for your device, just
> don't pretend it's FAT32.

But I do care and they do.
I created the Virtual Partition to support Live USB.
There is _absolutely_ no pretense here.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#6637

On Sat, 2 Apr 2016 18:55:34 -0400, "Mike Gonta" <mikegonta@gmail.com>
wrote:

>"Robert Wessel" wrote:
>> "Mike Gonta" wrote:
>
>>>I didn't know that defrag could/would do that.
>>>This is only for simple hobby OS's, etc - just don't
>>>defrag.
>>
>> Seems like a really user unfriendly policy: Don't do
>> something normally perfectly legal and often used.
>> Windows' built-in defrag is pretty basic.  Some of the
>> better ones have done drastically more work.  In any
>> event it's up to \you to prove it *won't* happen for some
>> reason.
>
>Fact is, it absolutely doesn't matter even if it did.
>Remember, the reason I am pre-allocating enough root
>directory cluster to provide at least 16 sectors is so that
>they are contiguous, defragging will only result in more
>contiguous sectors.


You have no assurance that defragging does not move the root
directory.


>The Virtual Partition protocol will only
>permit access to those first 16 anyways, so there will be
>no benefit gained (or loosed) by doing so. The business of
>the "fixed" location was only as analogy to the subset of
>the simple system FAT12 driver. To keep thing simple that
>driver "assumes" that the fat and root are located at a
>"fixed" locations and for simplicity "hard codes" these
>values in the code. But of course, in the FAT file system
>(even a 1.44MB floppy disk) any number of Reserved Sectors
>are permitted. Best programming practices dictate the the
>values should be calculated using the BPB. For an example
>of this check out the difference between the 16 bit real
>mode MikeOS http://mikeos.sourceforge.net/ and the 32 bit
>protected mode MikeOS FAT(ter)12
>https://github.com/mikegonta/MikeOS32
>Other than the fact that the latter is a PM32 translation
>of the former, the main difference is that I removed all
>the "hard coding" and thereby lifted the floppy disk
>restriction and "promoted" it to actual FAT12 (including
>hard drives).
>
>> I still don't get it.  Does the "standard OS" see this
>> "virtual FAT32"volume or not? Just part of it as a
>> (subset) of a "real" FAT32 volume?
>
>There is nothing "virtual" or "unreal" about the FAT32
>volume (only the Virtual Partition is virtual). There is
>_absolutely_ no modifications to the FAT32 volume. The
>Virtual Partition is only different from the standard
>FAT32 volume in the pre-allocation of the root directory
>clusters. The FAT32 root directory is like the
>sub directories which are like files. There is nothing in
>the specification that says you can not pre-allocate a
>file.
>
>> If so, how are you preventing the "standard OS" from
>> doing something that messes up the subset your device
>> needs to see?
>
>The Virtual Partition is 100% compatible with the
>specification. Short of hacking, stupidity and ignorance
>there is no way to "mess it up".


OK, I stick the device with this FS on it into a USB slot on my
Windows PC.  I fire up notepad to edit a text configuration file on
the volume (not really an uncommon way of doing things for embedded
devices with a removable storage device).  I'm assuming being able to
do this is a design goal here, yes?  So then notepad saves the file
using the usual write-temp-file, delete-old-file, rename-temp file
scheme, and at it's whim, it writes the new config file to a cluster
past 2048.

Or I happen to copy 16 clusters worth of directory entries to the root
directory of this device (and this may meet your definition of user
stupidity, but...), edit the config file with notepad, and the
directory entry for the temp file will end up someplace *after* the
first 16 clusters of the root directory, and it will not move during
the rename.  At this point I might delete all those extra files, but
that won't move the config file's directory entry.  So now the config
file is "lost" to the device, since it's no longer in the part of the
root directory it understands.

How are you going to prevent those scenarios?  You've dodged the
question repeatedly.


>>>3.  Only the simple system FAT32 driver knows about it.
>>>4.  The simple system FAT32 driver is exactly the same as
>>>    the FAT12 driver - the only difference is FAT32.
>>>5.  The simple driver can only see and access the files
>>>    in  the first 2048 clusters at the beginning of the
>>>    volume.
>>>    This is what makes it as simple as FAT12.
>
>> How do you ensure that the files you want are in either
>> the beginning of the root directory, or in the first
>> 2048 clusters of the volume?
>
>All files written to a FAT32 volume appear on the drive in
>the order they are written starting at the beginning of the
>data and root directory.


How do you justify that assertion?  The last allocated cluster thing
is, at best, a hint, and once may well be ignored by any FAT32
implementation.

[toc] | [prev] | [next] | [standalone]

#6616

Mike Gonta announced:

> http://forum.osdev.org/viewtopic.php?f=1&t=30254
> 
> 
> Mike Gonta
> look and see - many look but few see
> 
> http://mikegonta.com

It's already more than 20 years ago when I decided for 
a FAT-less filesystem for my OS.

I still kept my old routines to support at least read from 
any FAT(4..32 bit)-volume, but I wont ever use FAT for a 
system container.

So I'd ask why ? but may already see your reason in create 
and store your system files by DOS/windoze tools.

__
wolfgang 

[toc] | [prev] | [next] | [standalone]

#6619

"wolfgang kern" wrote:
> Mike Gonta announced:
>
>> http://forum.osdev.org/viewtopic.php?f=1&t=30254
>>
> It's already more than 20 years ago when I decided for a FAT-less 
> filesystem for my OS.
>
> I still kept my old routines to support at least read from any FAT(4..32 
> bit)-volume, but I wont ever use FAT for a system container.
>
> So I'd ask why ? but may already see your reason in create and store your 
> system files by DOS/windoze tools.

Hi Wolfgang,

The FAT file system (good/bad/or ugly) is used everywhere.
It's perfect for small bootable systems (hobby OS, games,
utilities, embedded systems, IOT).

The Virtual Partition enables a simple system FAT32 file
system driver to be as as simple as a FAT12 driver.


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.lang.asm

csiph-web