File: HACKING

package info (click to toggle)
ntfs 971218-4
  • links: PTS
  • area: main
  • in suites: hamm, slink
  • size: 692 kB
  • ctags: 670
  • sloc: ansic: 7,774; sh: 1,509; makefile: 232
file content (68 lines) | stat: -rw-r--r-- 2,632 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
Please read the README file before this one.

I Architecture of this distribution
-----------------------------------

The 'common' subdirectory contains the real NTFS engine.
All other directories are interfaces for this engine :
 linux20 : interface to the Linux kernel 2.0
 linux21 : interface to the Linux kernel 2.1
 44bsd : interface to the 4.4BSD kernel
 user : interface to a system user

II Bug tracking
---------------

If a Linux kernel interface crashes, check /var/adm/debug. If it works, but is
unreasonably slow, recompile w/o -DDEBUG.

You can also use the user interface to track bugs :

  ./ntdir

  This should give you a listing of the files. Once you found an interesting
  entry (say at offset 0x12F000), do

  ./ntdump --mft -o 0x12F000

  This should give you the list of attributes. Check whether the names file
  dates, and the size of the data attribute are reported correctly. Then, look
  at the data runs. Dump these to see whether file contents location is
  reported correctly.

  Use ntdir to locate the $AttrDef file. Locate the data runs either with the
  --mft option, or by looking at the hex dump, if the prior method fails. Look
  at the attribute names and numbers and compare them to what dump.c uses.

III Conclusion
--------------

Now you are in the position to start improving the NTFS driver. We are waiting
for your suggestions. Here is a ToDo-list :

1. Guessing parameters
   Most of these are solved, but there may be still some hidden assumptions
   about the size of things somewhere.
2. Guessing offsets
   The following offsets are obtained by guessing. It should be verified that
   they are really constant, or can be obtained from some other information
   on the volume:
   - Start of the attribute list in a MFT record (0x30)
   - Location of the attribute data for unnamed attributes (0x40)
   - positions of file access times in the standard attribute 
   (0x18, 0x20, 0x28)
3. Unused bytes/unsupported features
   As each byte in the infrastructure file probably serves a purpose,
   they should all be investigated. Also, some features known to be 
   implemented by NTFS are not supported in the tools. These include:
   - volume sets. What is the $Volume file for?
   - named and multiple data attributes
   - hard links and symlinks
   - Why appear name attributes to have access times, and why are there
   four access times, while only three are supported in the API (creation,
   modification, access)?
4. Comments
   Why can I never remember to put comments into source files?

Martin von L�wis <loewis@informatik.hu-berlin.de>
R�gis Duchesne <regis@via.ecp.fr>