Quote:
Originally posted by Undertoad
<i>I don't know if it's really a very closed format or if writing file system drivers is just really f'n difficult.</i>
I'm voting A. A filesystem format should be very easy to decode, right? Typically you'd have fixed lengths for most of the data in the directory, and anyone would be able to compare the filesystem from point A to point B. Having a filesystem format that's strangely complicated only invites corruption as developers try to keep up with it.
|
I imagine that it's pretty wildly complex, considering the number and power of the features that are included in NTFS. After a 5 minute browse on MS's site, I could only find some general programming information (only slightly more useful than .h files). The linux-ntfs site has some pretty detailed docs though.
Reading data from NTFS wouldn't be too difficult, once you cracked the trick to reading the MFT and a some of the other uber-hidden files on an NTFS partition. Writing data back out that was actually consistent and didn't hose a dozen other things would probably be a nightmare though. There looks to be about half a dozen metadta files that have to be updated along with directory entries, the journal, and the file data itself. Most of these operations probably have to be atomic too. Then there's quotas, reparse points, compression, encryption, and all that cool shit that NTFS can do. Ugh.