Pinto opened this issue on May 03, 2002 ยท 15 posts
praxis22 posted Fri, 03 May 2002 at 2:28 PM
Hi, At some point I'll read the entire thread before commenting... :) FAT is limited to 32Gb, NTFS isn't, (4 Terrabytes I think) Which is not to say you couldn't partiton a 100Gb drive into 3 if you wanted to go with FAT, but why would you if you had the choice? The program that's having trouble with NTFS is probably having trouble with the directory structure. It doesn't work like FAT32, (in that it has no FAT, [File Allocation Table]) NTFS uses a central directory structure that is always in the middle of the disk, this makes access time consistent, as it has a maximum seek time at the edge of the disk, getting quicker as it moves in. It's basically a big linked list. It also looks different at a low level, so if you're expecting FAT32 and you get NTFS it may behave, it may not, depending on the size and status of the filesystem itself. The two are fundamentally different. This means that you can't lose all your data by corrupting your FAT, (in NTFS) and because you have an essentially flat filesystem, you can only loose as much data as is contained on a corrupt physical disk block. The rest will remain readable, and possibly salvagable depending on they type of file. This is not the case if the FAT on a FAT32 file system dies, as then the drive has no idea where your data is. But with a linked list, (NTFS) even if the central directory gets shagged, you can stil find your data by following the links through the individual blocks themselves. To which the central directory is lookup table, a list of pointers. later jb