[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ntfs-dev
Subject:    NTFS documentation - Re: [Linux-NTFS-Dev] Hi, I'd like to help you...
From:       "Gerold J. Wucherpfennig" <gjwucherpfennig () gmx ! net>
Date:       2005-06-28 21:48:40
Message-ID: 200506282348.40992.gjwucherpfennig () gmx ! net
[Download RAW message or body]

please see below...

On Tuesday 28 June 2005 00:09, Szakacsits Szabolcs wrote:
> Hello Everybody,
>
> Gerold, sorry for the late answer, we were busy releasing ntfsprogs 1.10.0.
>
> Michiel, Matt, did you make progress collecting and preparing the TODO
> list? Please also feel free to tell if you have negative impressions for
> whatever reason.
>
> On Mon, 20 Jun 2005, Gerold J. Wucherpfennig wrote:
> > Hi folks I don't know if I can help you codingwise or documentationwise,
>
> Yes, in both ways.

FIRST:
After a few hours of searching I've found two other web sites which contain
a lot of NTFS documentation:
- http://littleharbor.com/ntfs-details.htm
- http://members.fortunecity.com/clark_kent/exjobb/report3.html

>
> > Last evening I thought about how to examine the log file / journal
> > structures of NTFS and here are my suggestions about how to get some
> > further information:
>
> We know enough about the log file. However full knowledge wouldn't be
> ignored :-)

I don't think so. I suppose there is enough knowledge to update the cluster
numbers when resizing a disk. But I'm sure there is not enough knowledge
to implement write support! (Actually I don't know much about NTFS.)


from @littleharbor.com/ntfs-details.htm:

"
Update records: There are two types of Update records: Undo and Redo. The
information provided by an Undo record may be used to reverse an operation
which has already been performed. The information provided by a Redo record
may be used to apply, or reapply, a given operation. The LFS logs all Redo and
Undo information for every transaction. The format of the information in
Update records is determined by the client using the LFS.
Update records may be either physical or logical information. Physical
information describes updates in terms of specific byte ranges which are to be
modified. Logical information expresses updates in terms of a logical
operation, such as "delete file README.TXT".
"

So not only the structures have to examined in detail, but all possible
values, too and that doesn't sound easy at all.

It has to be the very first thing to be done, no matter if you want to read or
write data of a NTFS volume, $LogFile and $UsnJrnl have to be known and
the NTFS recovery has to take place first.

This should be obvious, unexcusable, undiscutable and the 1. priority task.

From Cristian KLEIN <cristiklein@c7.campus.utcluj.ro>
"My main interest is to create a basic driver, which is able to 
read/write on a NTFS partition, without compression, encyption or 
journalling. After that, we may add all these features, however I am not 
sure they are essential, but it would be nice to have them for the sake 
of having an all-mighty NTFS driver."


<sorry no time to flatten this statement, I'm too tried>
Sorry, but this is the wrong approach. You can't do the easy tasks first! This
is not file system development, not even file system implementation,
but file system reverse/re engineering. You don't want to recreate the old 
ntfs driver with dangerous write support, don't you? You will never get that
stable and have to rework it x times. Instead first do the journaling
infrastructure, create one required feature, make sure it works 100% for you, 
do extensitive tests, release it to the public to let it be tested in the 
wild and then go on... Cristian, I think you're too optimistic and will loose
motivation when you realize how much effort this will take.
</sorry no time to flatten this statement, I'm too tried>


>
> > - use/engineer a windows driver for a virtual block device pointing to
> > some sectors of a real block device or a file. Having pause and resume
> > functions in this driver for examining "online" on disk structors.
> >
> > - an x86 emulator with the ability to auto pause and resume at disk
> >  write access.
> >
> > - I suppose a modified captive driver may not work, becaue capturing
> > changes of a running ntfs function call seems to be impossible.
>
> Thank you but no problem reverse engineering things. Just no time and
> enough people to do a lot of work still left.

I'm very interested in how you reverse-engineer the $LogFile file and it's
transaction-dependent settings. Tell me if you can reverse-engineer this
otherwise I will create my own virtual disk driver and will examine the
stuctures. When I won't have to reinvent the "wheel" things will
progress faster, of course.

>
> > BTW how far has write access progressed?
>
> Please see the status on the project's web site:
>
>  	http://linux-ntfs.sourceforge.net/status.html

That's very old stuff, I knew already. I thought there is some development
going on... ;-)       (Please forgive me, I could not resist...)

>
> The driver status maybe isn't fully up-to-date but it must be very close.
>
> > BTW what's missing in the documentation to implement ntfs write access?
>
> About nothing.

???

>
> > Please, please reply [...]
>
> Done :-)
>

Thanks, will you do that again?

Regards,
Gerold



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opĚk
_______________________________________________
Linux-NTFS-Dev mailing list
Linux-NTFS-Dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev

[prev in list] [next in list] [prev in thread] [next in thread]