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

Groups > linux.debian.user > #176257

Re: OT?: FAT32(/16?) Question: Max. files in top level

Show all headers | View raw

msdos 6.22 which was fat16 had a limit of 112 files in top level 
directory.  Once I tried putting more than that on a floppy disk and 
couldn't figure why no more would fit until I found this out.  I don't 
know if the limit got expanded for fat32 and msdos 7 but since Microsoft 
has been devoted to tearing stuff out of dos since msdos 6.22 I suspect 
that limit was not expanded.  In those days usb did not even exist so 
this information comes from pre-usb technology for me.  Hope this helps.

On Mon, 2 Jan 2017, David Wright wrote:

> Date: Mon, 2 Jan 2017 09:32:33
> From: David Wright <deblis@lionunicorn.co.uk>
> Reply-To: debian-user@lists.debian.org
> To: debian-user@lists.debian.org
> Subject: Re: OT?: FAT32(/16?) Question: Max. files in top level
> Resent-Date: Mon,  2 Jan 2017 14:37:55 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> On Sun 01 Jan 2017 at 13:15:11 (+0100), tomas@tuxteam.de wrote:
>> On Sat, Dec 31, 2016 at 05:14:50PM -0600, David Wright wrote:
>>> On Sat 31 Dec 2016 at 10:35:02 (+0100), tomas@tuxteam.de wrote:
>>
>> [...]
>>
>>>> Calculemus, as Leibnitz said. A bit of experimental informatics:
>>
>> Mpfh. Seems I was a bit boisterous here :)
>>
>> [...]
>>
>>>> Try this at home. Enjoy.
>>>
>>> I did, but I had some difficulty replicating your result. I took a USB
>>> stick and put a type c partition on it (mkfs.fat doesn't like writing
>>> whole devices). Then:
>>
>> Thanks for trying to replicate. Didn't know about the device thing. Will
>> try when I've an USB stick which isn't my main backup :)
>>
>>> #  mkfs.fat -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1
>>> mkfs.fat 3.0.27 (2014-11-12)
>>> Auto-selecting FAT32 for large filesystem
>>
>> OK, seems FAT32 has bigger limits (and it's actually selected when
>> the medium is big enough).
>>
>>> /dev/sdb1 has 62 heads and 62 sectors per track,
>>> hidden sectors 0x0800;
>>> logical sector size is 512,
>>> using 0xf8 media descriptor, with 3891199 sectors;
>>> drive number 0x80;
>>> filesystem has 2 32-bit FATs and 8 sectors per cluster.
>>> FAT size is 3793 sectors, and provides 485447 clusters.
>>> There are 32 reserved sectors.
>>> Volume ID is 20161231, volume label PETROLEUM2G.
>>> #
>>>
>>> I now ran your one-liner and created over 20,000 empty files
>>> at top level. So I down-sized with:
>>>
>>> # mkfs.fat -F 16 -i 20161231 -n PETROLEUM2G -r 2000 -v /dev/sdb1
>
> This was intended to create a FAT16 filesystem...
>
>>> mkfs.fat 3.0.27 (2014-11-12)
>>> /dev/sdb1 has 62 heads and 62 sectors per track,
>>> hidden sectors 0x0800;
>>> logical sector size is 512,
>>> using 0xf8 media descriptor, with 3891199 sectors;
>>> drive number 0x80;
>>> filesystem has 2 16-bit FATs and 64 sectors per cluster.
>>> FAT size is 256 sectors, and provides 60789 clusters.
>>> There is 1 reserved sector.
>>> Root directory contains 2048 slots and uses 128 sectors.
>>> Volume ID is 20161231, volume label PETROLEUM2G.
>>> #
>>>
>>> and now at last I could exhaust the top level directory with
>>> 1023 entries. As expected, df -h gives
>>> /dev/sdb1       1.9G     0  1.9G   0% /media/petroleum2g
>>
>> This is very interesting! Seems FAT32 has a limit of 1024 entries
>> in a top-level dir. OK, if all else fails, read the instructions :)
>
> ... so I think you mean FAT16 here.
>
>> Wikipedia [1] has a very informative page: according to that, on
>> FAT12 and FAT16, the root directory is statically allocated, and
>> its maximum size is written somewhere in the file system header.
>> There are two bytes available for that (and the number encoded
>> there is "number of entries"), so that in theory there could be
>> up to 65K. Lo and behold, mkfs.vfat *has* a command line parameter
>> (-r) to set the number of root directory entries! Of course, I'd
>> expect any overall limit on entries per directory to apply here,
>> if there is any (couldn't find that out in that short time).
>>
>> This all doesn't apply to FAT32 (as you had), where the root
>> directory is an ordinary directory. Why you got this 1024 limit
>> is thus still a mystery for me.
>
> So no mystery, perhaps.
>
>>> Like Nicolas I couldn't unpick Gene's rant about the subject as he
>>> doesn't seem to distinguish between DOS, the OS, and FAT, the
>>> filesystem used by DOS. But I wouldn't expect anyone using DOS
>>> seriously to need to have many files in top level directories.
>>> If the OP is lucky, the photo frame might create a subdirectory
>>> like most cameras/phones etc do, or, like some MP3 players, just
>>> display everything it encounters regardless of the subdirectory
>>> involved.
>>
>> Yeah, exactly. The only reason for FAT to exist these days is
>> compatibility, and then it makes sense to be especially conservative
>> (e.g. there's no limit to directory nesting depth, but most
>> implementations die on a path which is too long).
>>
>> Anyway, thanks for digging further!
>>
>> regards
>>
>> [1] https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
>
> Cheers,
> David.
>
>

-- 

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: OT?: FAT32(/16?) Question: Max. files in top level Xen <list@xenhideout.nl> - 2016-12-29 07:40 +0100
  Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2016-12-31 10:40 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 14:00 +0100
      Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2016-12-31 14:10 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 15:00 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Richard Owlett <rowlett@cloud85.net> - 2016-12-31 15:20 +0100
            Re: OT?: FAT32(/16?) Question: Max. files in top level Gene Heskett <gheskett@shentel.net> - 2016-12-31 16:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2016-12-31 16:40 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2016-12-31 16:30 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level David Wright <deblis@lionunicorn.co.uk> - 2017-01-01 00:30 +0100
      Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2017-01-01 13:20 +0100
        Re: OT?: FAT32(/16?) Question: Max. files in top level David Wright <deblis@lionunicorn.co.uk> - 2017-01-02 15:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level Jude DaShiell <jdashiel@panix.com> - 2017-01-02 16:30 +0100
            Re: OT?: FAT32(/16?) Question: Max. files in top level Nicolas George <george@nsup.org> - 2017-01-02 16:30 +0100
              Re: OT?: FAT32(/16?) Question: Max. files in top level rhkramer@gmail.com - 2017-01-02 17:40 +0100
          Re: OT?: FAT32(/16?) Question: Max. files in top level <tomas@tuxteam.de> - 2017-01-02 20:50 +0100
    Re: OT?: FAT32(/16?) Question: Max. files in top level Xen <list@xenhideout.nl> - 2017-01-01 12:50 +0100

csiph-web