View mode: basic / threaded / horizontal-split · Log in · Help
December 31, 2012
Re: Ranges longer than size_t.max
On 31/12/2012 17:50, Era Scarecrow wrote:
> On Sunday, 30 December 2012 at 19:11:51 UTC, Dmitry Olshansky wrote:
>> False. It's solely a question of FS used.
>> NTFS supports files larger then 4 Gb regardless of version Windows
>> (Win2K+ or even earlier). It doesn't matter what the bitness of OS in
>> question is. I suspect 32bit linux also has > 4Gb files even with ext2
>> no problem.
>>
>> And e.g. FAT32 remarkably can't handle 4 Gb+ files with any OS.
>
>   I was writing some code to go through the FAT12/16/32, and some
> interesting information was found (Although there was so much overhead I
> kinda stopped in the middle of it). FAT32 actually uses something like
> 28/29 bits for the sector id, the other 3-4 bits were flags like bad
> sectors, last sector and other minor data. At least that's what I
> remember off hand.

Sector?  Do you mean cluster?

I would have thought it used the whole 32 bits for cluster number, with 
magic values for "unused", "end of chain" and "bad".  In each case you 
don't need to point to the next cluster as well.  Unless it supports 
something like marking an in-use cluster as bad but leaving until 
another day the task of moving the data from it into a good cluster.

But looking through
>   http://en.wikipedia.org/wiki/Fat32

there are indeed a handful of magic values for things like this.

Anyway, that states that it uses 28 bits for the cluster number, but 
nothing about what the other 4 bits are for.

But a possibility I can see is that these 4 bits were reserved for bit 
flags that may be added in the future.

Stewart.
December 31, 2012
Re: Ranges longer than size_t.max
On Monday, 31 December 2012 at 18:55:04 UTC, Stewart Gordon wrote:
> Sector?  Do you mean cluster?

 Probably. They mean the same thing to me.

> I would have thought it used the whole 32 bits for cluster 
> number, with magic values for "unused", "end of chain" and 
> "bad".  In each case you don't need to point to the next 
> cluster as well.  Unless it supports something like marking an 
> in-use cluster as bad but leaving until another day the task of 
> moving the data from it into a good cluster.

 Wouldn't have been practical. Historically the FAT table was a 
layout of all the clusters that pointed to the next cluster, and 
used the largest number to denote EOF. (there were 8 codes or so 
reserved, I don't remember exactly).

 Taking the math if you were to lay it all out via FAT32 using 
the same scheme, you'd end up with 2^34 bytes for a single table. 
FAT by default had 2 tables (a backup) meaning 2^35 would be 
needed, that is just overhead (assuming you needed it all). Back 
then you had 8Gig drives at the most and space being sparse, 
28bits makes more sense (1-2Gigs vs 16gigs-32gigs). Of course 
obviously it wouldn't make the table(s) bigger if the drive 
didn't support above X clusters.

> But looking through
>>  http://en.wikipedia.org/wiki/Fat32
>
> there are indeed a handful of magic values for things like this.
>
> Anyway, that states that it uses 28 bits for the cluster 
> number, but nothing about what the other 4 bits are for.
>
> But a possibility I can see is that these 4 bits were reserved 
> for bit flags that may be added in the future.

 I don't remember where I read it, but I was certain they were 
used for overhead/flags; Course I was also reading up on Long 
File Name (LFN) too and directory structures. Likely lost 
somewhere in those texts.

 FAT32 would/could have supported files over 4Gig, however the 
Folder/FS Max filesize was 32bit, and anything over would have 
likely been more complex to incorporate, along with programs 
depending on them all being 32bit.

 Guess it was easier to make the hard limit rather than make it 
extend to further sizes. Plus programmers are going to be lazy 
and prefer int whenever possible. Hmmm actually back then long 
long's weren't supported (except maybe by gcc), so I don't think 
that was much an option.
January 02, 2013
Re: Ranges longer than size_t.max
On Sunday, 30 December 2012 at 22:08:59 UTC, Jonathan M Davis 
wrote:
> On Sunday, December 30, 2012 19:23:13 SomeDude wrote:
>> AFAIK, no 32-bit OS supports files larger than 4Gb anyway.
>
> Um. No. There's a reason that things like the macro 
> _LARGE_FILE_API exist.
> While some file systems won't allow larger file sizes, that's 
> generally an FS
> limitation, not an OS limitation. The OSes provide ways to 
> operate on 64-bit
> files on 32-bit systems. If they didn't, it would be impossible 
> to do something
> like read a Blu-ray on a 32-bit system.
>
> http://en.wikipedia.org/wiki/Large_file_support
>
> - Jonathan M Davis

That's true, I stand corrected.
Next ›   Last »
1 2 3 4
Top | Discussion index | About this forum | D home