|
From: Richard R. <nt...@fl...> - 2001-03-20 01:10:22
|
> Anon wrote:
> What's going on with this project - looks kinda dormant...
This project has just started and needs a bit of kick-start.
It sounds like a lot of work to rewrite everything, but a lot of the
original code was taken directly from test programs we wrote.
> Are the rpms and source here the same as the current linux ntfs
> drivers or is this different?
No, at the moment there are two streams. There's the original kernel
source which is static, except for bug fixes. Then there's the NTFS
project on SourceForge.
> I am not trying to be impertinent but why do you want to make new
> drivers? I have looked at the old drivers - they appear to me to be
> overly complicated and unclear. I have tried to follow the function
> calls and they get so deep that I lose track of the original purpose
> of the call.
Ha! You've answered your own question. The original driver WAS
complicated. Martin did a great job just starting the project off.
There was no documentation for NTFS when we started. It was a complete
nightmare. Anyway, the code evolved and never got reviewed.
Writing the code to /read/ NTFS was relatively simple, but as the write
code was started, the complexity of the code made things difficult.
It's still a much needed project, it's just hard work.
> ps: I hope you didn't write it....
[grins] linux/fs/ntfs/fs.c (line 6): Copyright (C) 1996 Richard Russon
> I don't understand why the writer didn't use structure pointers to map
> the on disk structure. Instead he used all these 'get' functions to
> get each value. Like in the standard data attribute for filesize he
> uses something similar to
> filesize= getu32( x );
> When it would have been much clearer to define
> struct stand_data {...
> unsigned long filesize;
> }
> And then the code could have just used d.filesize or d->filesize
> which is alot cleaner and clearer.
OK, this is a portability issue. The GETU32 macro (and its friends)
convert between disk (little-endian) format and memory (cpu) format.
On the i386 architecture, the conversion is a null op. On an Alpha
however, the byte order has to be reversed. The other reason for all
those macros is that field lengths vary between compilers. Rather than
using short, long, etc we use ntfs_u16, ntfs_u32, etc.
> I applaud the guy who wrote it... it does work but, I think the code's
> complex. It works but its difficult to follow, modify and maintain.
Anton's idea is to rewrite all the user tools from the ground up, with
all our current knowledge, and THEN try to rewrite the driver.
Cheers,
FlatCap (Rich)
nt...@fl...
|
