FAT is not limited in file size because of anything to do with it being block-based: the limiting factors are the size of the field in directory entries for expressing file sizes, and the size of the FAT it self, as blocks are stored in a indirection table (which can be thought of as a linked list.)
Following on to that, it's not just because NTFS supports extents that it supports files larger than 4GB.
NTFS has case-sensitivity, for POSIX compliance. The Windows API hides this.
Keep up the good work
Folks, I have been reading yakking for 3? 4? years now and your articles have been a very valuable source to refer to co-workers and friend when they were asking about some topics. And even for relearning about some topics myself. Thank you!
Comment by
ana
—
start here page
Nice collection of articles! Might be helpful to have a "start here" page for people new to the site - also grouping things by technical level. For example the introduction to... series could be tagged somehow so people can just start off with the basics.
Comment by
abhidg
—
There's a lot of guides out there on how to correctly handle a signal,
seems like the kind of topic this blog would cover nicely,
maybe include the following point? which seems to be missed in examples I've seen.
FAT is not limited in file size because of anything to do with it being block-based: the limiting factors are the size of the field in directory entries for expressing file sizes, and the size of the FAT it self, as blocks are stored in a indirection table (which can be thought of as a linked list.)
Following on to that, it's not just because NTFS supports extents that it supports files larger than 4GB.
NTFS has case-sensitivity, for POSIX compliance. The Windows API hides this.
There's a lot of guides out there on how to correctly handle a signal, seems like the kind of topic this blog would cover nicely, maybe include the following point? which seems to be missed in examples I've seen.
ftp://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_24.html#SEC488