|
From: Szakacsits S. <sz...@si...> - 2004-05-08 20:32:23
|
On Sat, 8 May 2004, Anton Altaparmakov wrote: > On Sat, 8 May 2004, Szakacsits Szabolcs wrote: > > > Were these done recently or BK has some datum bugs? It says these > > 2.2.0-WIP changes were done in 2002 :-o > > Correct! It was a looong time ago. I never had time since to work on it > really... and since it had the deadlock I couldn't just merge/release it > so it has been dormant since then. I wasn't aware there are more code, otherwise probably I would have checked it out for the problems ... Do you remember when over a year ago we debugged and fixed a deadlock what people sometimes reported? http://archives.mandrakelinux.com/cooker/2003-02/msg00285.php http://archives.mandrakelinux.com/cooker/2003-02/msg00538.php Isn't it possible you still mean this bug, just forgot about it that's why you can't reproduce anymore? > I am afraid it is quite possible that my plans have only ever existed > on IRC and/or private emails... Potential sponsors would be interested also, I'm quite sure ;-) > > Your original sentences suggested for me that significant changes, new big > > features are coming soon what apparently I misunderstood. > > Not that soon, no. Although having resident file overwrite is a pretty > important feature. I totally agree. Probably I wasn't clear either, I do know a lot of work is needed still and even something that looks a trival feature or non-feature can take a long time to get done properly by careful, hard work. I just thought you became a beneficent millionaire or someone seriously started to sponsor the development ;-) > And being able to write mft records / dirty inodes is a pretty big > feature for the driver internals as it allows all sorts of code to be > added in various places to do different things. Of course I agree. I wasn't aware this code already exists in the development tree, I thought it's the same as the one in the kernel so I've never checked it out. Anyway, the above is a very good news. > E.g. allows to start on file truncation support which means you can > write and resize files. Yes, create, unlink, truncate would be the most important next steps, I think. > It also allows work on access time updating to start. And if anyone > is so inclined (FlatCap was working on this but he is deNTFSing his > life at the moment...) directory writing code can start to be added. > All sorts of things can start happenning really... Anybody is working on anything related? Either user space or kernel space? I'm aware of your ntfstruncate but nothing else. > I will get back to you at a later time with what my personal plans for > working on the driver look like. Great. These should be summarzed on the web also somehow IMHO. Something that what and how people could help. Not necessarily kernel coding but also updating, cleaning documantation, web pages, testing, etc. There would be many ways to help out. Cheers, Szaka |
