Hi,
On Tue, 21 Oct 2003, Jan Kratochvil wrote:
On Tue, 21 Oct 2003 22:38:41 +0200, Szakacsits Szabolcs wrote:
I guess you mean reading? Anyway it depends on the driver quality. All needs to be known for both read and write.
Not all information needs to be known for reading:
It depends on the driver quality. All needs to be known for both read and write. In other words, one must know how the system works if he/she wants _reliable_ reading, aka the data one read is trustable, not some bogus value.
For exmaple the block allocation bitmap is used for filesystem consistency check by ntfsresize.
Consistency is an addon useful feature although it is not required for successful reading.
Again, depends on quality. Specifically we are talking about NTFS, right? Below is one of the many rebuttals from practice.
Partimage supports NTFS (experimental). It was implemented based on the public NTFS documentation (it doesn't use the Linux-NTFS source base). For example it doesn't check the filesystem consistency, just saves the blocks marked in use in the block allocation bitmap ($Bitmap). Thus if the filesystem is inconsistent (it do happen) then it will save the wrong blocks: it might save what are unused and/or what's really fatal, it doesn't save what are in use. Lost data.
I spoke about OS/2 as an example of a split NTFS development. As I hope you agree it is not appropriate to split the development of NTFS filesystem in a way incompatible with Microsoft Windows NT.
If you have source you can make transparent extensions or just fork it and do whatever needed. Many open source project do this, it's one of the strength of open source.
But I can't see such "danger". NTFS is pretty modular, plugin-like, something what Reiser4 promises (but Reiser4 looks even cooler). MS just plugged in what people need: compression, encryption, quota, link, WinFS support, etc.
It may be true but at the start of my Captive NTFS project coding there was no free implementation of read/write NTFS.
No-one should expect NTFS kernel driver to be done in the near future unless active development starts. But because people think NTFS is undocumented (untrue) the chances are even smaller than it could be (and those who could do it don't have the time for it).
As I do not trust reverse engineered complex data structures for such sensitive content as the user data
The reverse engineered, complex data structures were validated and in use for years.
I implemented the read/write NTFS in a way most reliable in my opinion.
Ok, I don't repeat here what I wrote on the other list, if one is interested he/she can read it here:
http://reactos.com:8080/archives/public/ros-kernel/2003-October/000294.html
Just a new one, robustness. I didn't test Captive NTFS but looking at the system design it's a bit too complex. Error-prone. With a variable black box (there are a lot of different ntfs.sys) in the middle. Sorry but I wouldn't trust it for a minute. I sincerely hope I will be disproved by millions of happy users.
BTW there is still no non-Captive free implementation of read/write NTFS.
How long did it take to implement Captive NTFS? My estimation for a free (full GPL) r/w implementation is
needed kernel knowledge: 3-9 months if one doesn't have it yet NTFS knowledge: 1-3 months if one doesn't have it yet finish r/w NTFS v2 driver: 2-6 months
Szaka