linux-ntfs-dev — Development discussions and bug reports.

Re: [Linux-NTFS-Dev] gcc 2.95

[Anton A. <ai...@ca...>]

Hi,

Just for benefit of people reading the list but not knowing what is going 
on due to Rich and I talking on #ntfs (on IRC on openprojects.net, everyone 
welcome) here is a brief reply...

At 04:11 25/02/02, Richard Russon wrote:
>N.B.  If you're still in Austria STOP reading and START skiing.

I didn't check email from Austria at all. Whenever I walked past the local 
internet cafe I managed not to walk into it. (-:

>I've just spent a while playing about getting anonymous structs and
>unions compiling under gcc 2.95.  After lots of strange and unusual
>ideas, I've come up with something that works well, looks OK and is
>easily removeable.

Yes, that is great.

>I've converted all the TNG code and it now compiles with gcc 2.96,
>gcc 2.95 and egcs 2.91.66.  Moreover the driver works :-)

Excellent.

>At the moment the macros are in scripts/ntfsextra.h and a forcibly
>included.  In this state the code needs a minor bit of rearranging
>to compile inline in the kernel source.

That is now fixed so the code will compile in the kernel fine. No 
rearrangements necessary. Once the kernel's compiler requirements are 
raised to gcc-2.96 or above, all the macros, etc will be blasted into 
oblivion making the driver nice and clean again.

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] utf8

[Anton A. <ai...@ca...>]

At 16:15 01/03/02, eawalth wrote:
>I was using uni_xlate in an earlier version of the NTFS driver (the
>driver in the linux 2.4.4 kernel) to mount a ntfs partition. This
>feature is no longer supported.

Correct. I removed the mount option and all associated code as it was not 
working properly (it was not fully implemented, i.e. only the readdir and 
lookup methods implemented it). Further, the translations were using the 
colon which is a reserved ntfs character (denoting named streams in 
Windows) which I don't want to see used for anything else as it is bound to 
break things in the future.

>I have tried iocharset=utf8 and utf8=1 options, but they don't translate 
>the text correctly. I do not get numbers--I get characters. Is this not 
>working or am I doing something wrong.

The utf8 options do translate the text correctly and no you are not doing 
anything wrong. As their name suggests they translate into UTF-8 which is 
an ASCII compatible multi-byte Unicode encoding (with eight bits per byte) 
encoding. It is up to the user to be using correct terminal 
emulators/settings which understand UTF-8 and have the appropriate fonts so 
the characters can be displayed properly.

So yes, you get characters and not numbers expressed as text and this is a 
feature, not a bug.

What exactly is the problem this is causing to you?

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] utf8

[eawalth <ea...@sa...>]

I was using uni_xlate in an earlier version of the NTFS driver (the
driver in the linux 2.4.4 kernel) to mount a ntfs partition. This
feature is no longer supported. I have tried iocharset=utf8 and utf8=1
options, but they don't translate the text correctly. I do not get
numbers--I get characters. Is this not working or am I doing something
wrong.

Eleanor Walther

[Linux-NTFS-Dev] gcc 2.95

[Richard R. <nt...@fl...>]

Hi Anton,

N.B.  If you're still in Austria STOP reading and START skiing.

I've just spent a while playing about getting anonymous structs and
unions compiling under gcc 2.95.  After lots of strange and unusual
ideas, I've come up with something that works well, looks OK and is
easily removeable.

There are two macros SN (Struct Name) and SC (ShortCut).  These are
used to add names and hide the depth of the structures.  Next each
deepest struct needs its own macro; there is no other way.  I tried
macros, preprocessing, sed scripts, but to no avail.  Examples...

#define SN(X)   X
#define SC(P,N) P.N

struct {
	union {
		struct {
			char *attr_name;
		} SN(man);
		struct {
			int attr_len;
		} SN(mal);
	} SN(mua);
} MFT;

#define _MAN(X)  SC(mua.man,X)
#define _MAL(X)  SC(mua.mal,X)

I've tried to pick TLAs that are memorable.  The first letter is the
from the name of the whole struct and the second and third a reminder
of the inner-most struct.  The leading underscore was a vague attempt
at avoiding name clashes.

With gcc 2.96 the usage was:

  MFT m;
  m.attr_name = "xyz";

now it becomes:

  m._MAN(attr_name) = "xyz";

The union's name is hidden away.  This approach reduces the complexity
in the code (memorable macro names) and the header files aren't made
illegible either.

I've converted all the TNG code and it now compiles with gcc 2.96,
gcc 2.95 and egcs 2.91.66.  Moreover the driver works :-)

At the moment the macros are in scripts/ntfsextra.h and a forcibly
included.  In this state the code needs a minor bit of rearranging
to compile inline in the kernel source.  The alternative is to
pre-process out the macros.  I've created a couple of scripts to do
exactly this.  scripts/create95 outputs gcc 2.95 compatible source
and scripts/create96 gives source suitable for gcc 2.96+.

I've checked the changes into the trunk of CVS.  One excuse (too
much hassle to create a branch) and one reason (hopefully you'll be
happy with the changes :-).  I tagged the code beforehand for safety's
sake "pre-95".

Cheers,
  FlatCap (Rich)
  nt...@fl...

Re: [Linux-NTFS-Dev] confused about runlists

[Richard R. <nt...@fl...>]

Hi Jeff,

Argh!  People are hexing me.  Make them stop :-)

> I'm trying to understand how NTFS works, so I'm looking at runlists on a
> Windows XP volume with a hex editor.

Cool.

> I understand how to interpret the runlist as it appears in the example in
> the online documentation.  I've come across something without a
> corresponding documentation example, though.

Ah!   You're missing one crucial piece of information: fixups.
The MFT is "protected".  For a full description have a look at:

  http://linux-ntfs.sourceforge.net/ntfs/concepts/fixup.html
  http://linux-ntfs.sourceforge.net/ntfs/concepts/file_record.html

Briefly, the last two bytes of each sector are copied into the
MFT header and a sequence number is written in their place.
Each time the MFT is changed, the seq num is incremented.
When we read the MFT we have to un-fixup the record before
working with it.

> ...
> 10: 21 01 2E FF  21 01 52 EC  21 01 E5 14  31 01 30 3F
> 11: FF 31 01 C8  A1 FE 21 01  B7 FB 21 01  3E 23 66 00
> 12: 94 00 11 01  19 21 01 AA  6E 21 01 27  13 21 01 93
> ...

Once you've removed the fixup I predict the line will look like:

> 11: FF 31 01 C8  A1 FE 21 01  B7 FB 21 01  3E 23 21 xx

giving you a run of xx clusters @ +0x94.

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] confused about runlists

[Jeff M. <je...@bo...>]

I'm trying to understand how NTFS works, so I'm looking at runlists on a
Windows XP volume with a hex editor.

I understand how to interpret the runlist as it appears in the example in
the online documentation.  I've come across something without a
corresponding documentation example, though.

Here's the runlist...

01: 31 01 B8 88  00 31 01 1C  A1 00 21 02  02 03 31 04
02: 02 4A FF 21  08 11 D4 21  10 D5 37 11  01 1B 11 01
03: 08 11 01 04  11 01 04 11  01 04 11 01  06 11 01 BA
04: 11 01 EE 21  01 CB F7 21  01 2C FA 11  01 FC 21 01
05: 80 F6 21 01  4F FD 11 01  FC 11 01 FC  11 01 FC 11
06: 01 FC 21 01  70 F5 21 01  9F F8 21 01  7C FF 11 01
07: F4 11 01 FA  21 01 0F FF  21 01 D2 FE  11 01 DD 21
08: 01 16 DC 21  01 2D 61 11  01 2C 21 01  83 08 31 01
09: 73 00 02 11  01 F5 31 01  72 98 FD 31  01 80 6A 02
10: 21 01 2E FF  21 01 52 EC  21 01 E5 14  31 01 30 3F
11: FF 31 01 C8  A1 FE 21 01  B7 FB 21 01  3E 23 66 00
12: 94 00 11 01  19 21 01 AA  6E 21 01 27  13 21 01 93
13: 24 21 01 EA  66 31 01 B3  EB 00 21 01  7A 01 21 01
14: 03 F5 21 01  32 04 21 01  FE 10 21 01  7E FE 21 01
15: DA FD 11 01  F5 11 01 A9  11 01 CA 11  01 97 11 01
16: FC 11 01 D9  11 01 B0 11  01 D0 11 01  B3 11 01 CE
17: 21 01 7C FE  11 01 A5 21  01 6B EF 21  01 3E FF 21
18: 01 BF 00 21  01 A8 FD 31  01 A6 76 FF  11 01 DB 11
19: 01 FC 31 01  25 2D FE 21  01 93 1F 21  01 7A 08 31
20: 01 DB F6 00  21 01 67 15  21 01 C1 24  21 01 0E 79
21: 21 01 2C BB  21 01 9D BE  31 01 71 F9  00 31 01 25
22: AE FE 21 01  BF 0E 21 01  E6 13 31 01  22 0C 01 21
23: 01 D0 26 31  01 87 82 00  21 01 68 07  21 01 98 00
24: 11 01 4C 11  01 5D 11 01  45 11 01 60  11 01 6F 21
25: 01 D4 0D 11  02 4B 11 01  42 11 01 4F  21 01 17 01
26: 21 01 8E 01  21 01 13 D1  21 01 E3 F4  21 01 81 E0
27: 21 01 20 FF  21 01 24 FE  21 01 64 F1  11 01 FE 11
28: 01 FE 21 02  1C 02 11 01  42 11 01 3B  11 01 43 11
29: 01 76 21 01  AC FC 11 01  FE 21 01 9D  FE 21 01 4B
30: 6C 31 01 53  46 FF 31 01  82 D5 FD 31  01 9E D1 02
31: 11 01 43 31  01 B0 E6 00  21 01 54 01  11 01 08 11
32: 01 10 31 01  ED 81 FD 11  01 02 21 01  B7 01 00 00

I can't figure out what's going on with line #11, starting at second to
last column.  The value there is 0x66, and I was expecting to find a
header byte.  0x66 could, in theory, be a valid header byte, but not in
this case.

I guess this is the "gathered elements" or "coalesced entries" mentioned
in the docs.  It's my understanding that the 4 bytes starting with 0x66
are in fact two entries specifying only an offset, with length inherited
from the first entry.

H- L- O----
21 01 3E 23
      66 00
      94 00

Is that correct?  If so, how are you supposed to know that the byte 0x66
is a gathered element instead of a new header byte?

Thanks!
-Jeff M

[Linux-NTFS-Dev] NTFS TNG road map

[Anton A. <ai...@ca...>]

There is interest in this information so here is the current status and 
future plans for NTFS TNG.

NTFS TNG driver (currently kernel 2.5.x)
========================================

This is a driver I started from scratch because the old driver was just too 
broken and using too old interfaces (buffer cache) and IMO bad approaches 
to things in NTFS.

It is modern, much cleaner code and hence easier to understand. It uses all 
the latest technologies and it is coming along nicely.

The driver is only for 2.5.x kernels at the moment but can be made to work 
with minor modifications under 2.4.x kernels, too. In fact my plan is to 
submit the driver for inclusion into the 2.5.x kernels and once it is there 
and has had good testing to back port and submit for inclusion into 2.4.x 
kernels.

The present state is that read support is almost complete to the extent of 
offering the same functionality as the old driver. The only thing currently 
unfinished is support for Attribute List Attributes but that is under 
development at present. Once this is finished, the driver will need to 
undergo some very serious testing/QA. After I test it myself as much as 
possible and cannot break it any more I will be looking for people to test 
it on their systems, especially I will need people with MultiProcessor 
systems as well as people using other architectures than Intel 32-bit CPUs, 
to test the driver. Unfortunately I cannot afford an SMP system (I used to 
have a dual Pentium 2 but when the motherboard fried itself, I could only 
replace it with a single CPU board) and similarly I do not have access to 
non-ia32 computers running Linux on which I could test...

Assuming testing is successful, I will immediately submit the driver to 
Linus for inclusion into 2.5.x. I intend to remove the old driver and 
replace it with the new one completely. (For the later 2.4.x back port I 
might well leave the old driver there for people who don't trust the new one.)

At this point I will begin working on write support in the new driver. Work 
will be done outside the kernel tree in CVS (Sourceforge hosts my 
linux-ntfs project including the ntfs and ntfs tng drivers). This will be 
done in distinct stages and once each stage is complete and tested locally 
it will be submitted for 2.5.x, then back ported to 2.4.x once proven to 
work well.

The stages as I envision them at the moment are as follows:

1. On write mount, erase the contents of the journal ($LogFile). At the 
beginning the user might just be required to run ntfsfix (from linux-ntfs 
package on Sourceforge or we might do some hack ish solution until we have 
proper write support in one of the latter stages).

2. Implement writing of dirty inodes (this will allow ATIME updates for 
example) to disk and is really a pre-requisite to any further writing 
abilities.

3. Implement file truncation.

4. Implement modification of existing files (i.e. both overwrite of 
existing data in file and extend/shorten file with help from file 
truncation implemented above in 3). - Initially only uncompressed files. 
Either compressed files will be decompressed and then written uncompressed 
or we refuse to write to compressed files altogether.

5. Add compressed file write support. (This point may well come much later, 
the old driver doesn't allow this either.)

6. Implement file deletion.

6b. Disable the $UsnJrnl, the user accessible high level journal. (Windows 
can reenable on reboot.)

7. Implement directory removal. (Possibly together with 6 in one step, or 
possibly before 6).

8. Implement file creation.

9. Implement directory creation. (Possibly together with 8 in one step, or 
possibly before 8).

At this point we have everything the old driver has and more (removal of 
files and directories) but it is now working.

Now come the extra features. The first is going to be hard links as those 
are trivial to support on NTFS. Then in random order there will be support for:

- security (ACL) (requires mapping between Windows user ids and Linux ones)

- quotas (requires mapping between Windows user ids and Linux ones)

- named streams

- extended attributes (EA)

- Microsoft's BackupAPI (possibly with help from user space library)

- on-line growing of the file system (this one is trivial to implement)

- on-line defragmentation

I think that covers everything except the following, which are going to be 
major pains to implement and we may never bother:

- symbolic links/mount points/off line storage/etc (reparse points in NTFS)

- encrypted files (requires mapping between Windows user ids and Linux 
ones, as well as extracting copies of the decryption keys from Windows 
where ever it may be storing them)

- $UsnJrnl journal support

- $LogFile journal support

I have been told by someone that $LogFile is protected by multiple patents 
and if this is true we will not be able to ever implement it I fear... In 
that case or should it be too much work, Linux might get its own journal so 
at least it is journalled while in Linux. The only problems/points of 
failure would then be reboots in between Windows and Linux.

I hope that gives everyone some idea of where ntfs tng is at on Linux now 
and which way it is heading.

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] What tool can I use to view the harddisk dump in HEX code?

[Anton A. <ai...@ca...>]

At 15:00 14/01/02, Richard Russon wrote:
> > or hexdump, etc.
>
>That's what I use.  It's extremely configurable.
>I have aliased hexdump as:
>
>alias dump='hexdump -f ~/.format'
>
>and created a file ".format" which contains:
>
>"%06.6_ax  "
>8/1 "%02X " " - " 8/1 "%02X "
>"  " "%_p"
>"\n"
>
>
>Now my output looks like:
>
>000000  46 49 4C 45 2A 00 03 00 - 0D 6E 06 02 00 00 00 00  FILE*....n......
>000010  01 00 01 00 30 00 01 00 - 90 01 00 00 00 04 00 00  ....0...........
>000020  00 00 00 00 00 00 00 00 - 06 00 26 00 00 00 00 00  ..........&.....

Cool, thanks for the tip. I have been wondering how to do this output 
format with hexdump... never bothere to go to such depths...

hexedit has the same output (pretty much) but it has the advantage of being 
able to actually edit in place as well as seek to wherever you want and it 
even has a "sector" mode where you can seek to any sectors with the obvious 
advantage that when you read off a mapping pairs array for example you can 
decompress it by hand on a piece of paper and then immediately seek to the 
right sectors to look at the contents. In sector mode it's just "press 
enter", enter sector number to seek to, "press enter"... I guess it boils 
down to hexedit being interactive and hexdump only being a dump tool, but 
every one has their pet tools... (-;

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] What tool can I use to view the harddisk dump in HEX code?

[Richard R. <nt...@fl...>]

> or hexdump, etc.

That's what I use.  It's extremely configurable.
I have aliased hexdump as:

alias dump='hexdump -f ~/.format'

and created a file ".format" which contains:

"%06.6_ax  "
8/1 "%02X " " - " 8/1 "%02X "
"  " "%_p"
"\n"


Now my output looks like:

000000  46 49 4C 45 2A 00 03 00 - 0D 6E 06 02 00 00 00 00  FILE*....n......
000010  01 00 01 00 30 00 01 00 - 90 01 00 00 00 04 00 00  ....0...........
000020  00 00 00 00 00 00 00 00 - 06 00 26 00 00 00 00 00  ..........&.....

FlatCap (Rich)
nt...@fl...

Re: [Linux-NTFS-Dev] What tool can I use to view the harddisk dump in HEX code?

[Anton A. <ai...@ca...>]

I use "hexedit /dev/hda". If you don't have hexedit, you can get it from:

http://www.chez.com/prigaux/hexedit-1.2.2.src.tgz

or precompiled i386 binary:

http://www.chez.com/prigaux/hexedit-1.2.2.bin.i386.dynamic.tgz

If you also have Windows, then the Microsoft NTFS diskedit.exe program 
(present on NT4 Service Pack 4 CDROM) is a fantastic tool as it not only 
does hex dumps but it also interprets the ntfs structures and displays 
their content intelligently.

Best regards,

Anton

At 10:46 14/01/02, WanYu Lin wrote:
>Dear all,
>
>For the being I am tracing the Linux ntfs module and I want to view the NTFS
>formats on harddisk in HEX code.
>Does anyone know what tool I can use to view them on Linux paltform?
>I have tried "dd", but it could just show some garbage character code.
>
>Cheers,
>Alex
>
>_______________________________________________
>Linux-NTFS-Dev mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-ntfs-dev

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] What tool can I use to view the harddisk dump in HEX code?

[Andrew C. <cl...@gn...>]

On Mon, Jan 14, 2002 at 06:46:24PM +0800, WanYu Lin wrote:
> Dear all,
> 
> For the being I am tracing the Linux ntfs module and I want to view the NTFS
> formats on harddisk in HEX code.
> Does anyone know what tool I can use to view them on Linux paltform?
> I have tried "dd", but it could just show some garbage character code.

cat /dev/hda1 | xxd

or hexdump, etc.

Andrew

[Linux-NTFS-Dev] What tool can I use to view the harddisk dump in HEX code?

[WanYu L. <Wan...@vi...>]

Dear all,

For the being I am tracing the Linux ntfs module and I want to view the NTFS
formats on harddisk in HEX code.
Does anyone know what tool I can use to view them on Linux paltform?
I have tried "dd", but it could just show some garbage character code.

Cheers,
Alex

[Linux-NTFS-Dev] ANN: Linux-NTFS 1.5.0 released

[Anton A. <ai...@ca...>]

This is to announce release of Linux-NTFS user space support tools 1.5.0.

This release fixes several bugs and contains multiple feature enhancements. 
Upgrade is strongly recommended.

Most important changes:

    * It was requested for libntfs that a read-only mount become possible 
so the syntax for ntfs_mount is now changed to accept the MS_RDONLY flag.

    * Further it was requested to fix compilation on other architectures. I 
hope I achieved this but I don't have any other arch, so please complain if 
it doesn't compile on your arch.

    * For detailed list of changes see the ChangeLog below.

Linux-NTFS packages (your choice of source tar.gz or rpm, binary i386.rpm 
and devel rpm, debian packages only available for 1.4.0 release) can be 
downloaded from the Linux-NTFS home page at:

         http://linux-ntfs.sf.net/

Or if you prefer CVS access, look at the project home page on Sourceforge 
for details how to access the CVS server:

         http://sourceforge.net/cvs/?group_id=13956

ChangeLog:

1.5.0:

* Fix bug in $LogFile size calculation where we would take the size to be 
zero on partitions between 200 and 400MiB in size.
* Add requirement for linux-ntfs to linux-ntfs-devel rpm.
* Remove atomic ops and add compiler version check. Hopefully this will 
preempt "it doesn't compile for me" messages from people with gcc < 2.96.
* Change bail out error check for seek to backup boot sector to a warning 
since SuSE 7.2 + loads of stuff and 2.5.1-pre11 returns EINVAL instead of 
ENOSPC.
* Remove atomic code as it isn't defined on non-i386 arches.
* Change ntfs_mount to accept second argument for mount flags. - 
ntfs_mount() now supports mount flags as per "man 2 mount". Currently only 
the MS_RDONLY flag is supported/implemented. This breaks compatibility with 
older libntfs versions and hence the major version number of the library 
has been increased.
* Adapt utilities to make use of new ntfs_mount syntax.
* Add description of compression algorithm.

For older changes, see the ChangeLog file in the release or in CVS.

Best regards,

Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] Re: ntfs on 2.4.12-0.1

[Anton A. <ai...@ca...>]

Already fixed in 2.4.17.

Best regards,

Anton

ps. This might have been replied to already (I am catching up with email 
backlog now).

At 01:47 21/12/01, Goldencat wrote:
>mounting winXP file system with readonly.
>cd /mnt/xp
>cd WINDOWS
>ls
>segment fault
>
>
>NTFS driver v<3>NTFS: Warning! NTFS volume version is Win2k+: Mounting
>read-only
>------------[ cut here ]------------
>kernel BUG at fs.c:308!
>invalid operand: 0000
>CPU:    0
>EIP:    0010:[<d095f539>]    Tainted: P
>EFLAGS: 00010286
>eax: 00000018   ebx: 00000000   ecx: 00000001   edx: 00002228
>esi: c71c51fc   edi: c62a2b54   ebp: c45d3f4c   esp: c45d3ef4
>ds: 0018   es: 0018   ss: 0018
>Process ls (pid: 22472, stackpage=c45d3000)
>Stack: d096a2dc 00000134 00060003 00000000 c71c51fc c0144800 00000002
>00000006
>        00000003 c45d3fa0 00000000 00000000 ffffffea 00000004 00000000
>00030002
>        c3e43ef4 c0126ab4 00000301 c71c51fc c71c5284 c71c5260 c62a2b54
>c0144420
>Call Trace: [<d096a2dc>] __insmod_ntfs_S.rodata_L640 [ntfs] 0x35c
>[<c0144800>] filldir64 [kernel] 0x0
>[<c0126ab4>] do_munmap [kernel] 0x64
>[<c0144420>] vfs_readdir [kernel] 0x60
>[<c0144800>] filldir64 [kernel] 0x0
>[<c014498f>] sys_getdents64 [kernel] 0x4f
>[<c0144800>] filldir64 [kernel] 0x0
>[<c0106f2b>] system_call [kernel] 0x33
>
>
>Code: 0f 0b 83 c4 10 83 7d d8 00 75 18 ff 77 24 ff 77 20 68 60 b2
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to maj...@vg...
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: [Linux-NTFS-Dev] ntfs on 2.4.12-0.1

[Richard R. <nt...@fl...>]

Hi Goldencat,

> kernel BUG at fs.c:308!

Thanks for the bug report and sorry it's caused you trouble.

There are a couple of simple fixes:
  upgrade to 2.4.17 where Anton has removed the BUG();
  don't compile with DEBUG enabled
  remove the BUG(); (fs/ntfs/fs.c line 308) and the 'if' before it

Hope this helps,
  FlatCap (Rich)
  nt...@fl...

P.S. Anton's still on holiday.

[Linux-NTFS-Dev] Linux LDM v0.0.5 (Windows Dynamic Disks)

[Richard R. <nt...@fl...>]

Hi All,

I've just released 0.0.5 of the LDM code.
It can be downloaded from:

  http://linux-ntfs.sf.net

Briefly, the major changes are:

  It's much more efficient (the database is cached)
  Support for md autodetection
  A new tool (ldmutil) to tweak the LDM database
  Numerous bug-fixes

Most of the credit goes to Jakob Kemi who's been doing
a marvellous job (though it took a while for me to understand
/what/ he's been doing :-).

Any questions or comments, please email me.

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] ntfs on 2.4.12-0.1

[Goldencat <gol...@ez...>]

mounting winXP file system with readonly.
cd /mnt/xp
cd WINDOWS
ls
segment fault


NTFS driver v<3>NTFS: Warning! NTFS volume version is Win2k+: Mounting
read-only
------------[ cut here ]------------
kernel BUG at fs.c:308!
invalid operand: 0000
CPU:    0
EIP:    0010:[<d095f539>]    Tainted: P
EFLAGS: 00010286
eax: 00000018   ebx: 00000000   ecx: 00000001   edx: 00002228
esi: c71c51fc   edi: c62a2b54   ebp: c45d3f4c   esp: c45d3ef4
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 22472, stackpage=c45d3000)
Stack: d096a2dc 00000134 00060003 00000000 c71c51fc c0144800 00000002
00000006
       00000003 c45d3fa0 00000000 00000000 ffffffea 00000004 00000000
00030002
       c3e43ef4 c0126ab4 00000301 c71c51fc c71c5284 c71c5260 c62a2b54
c0144420
Call Trace: [<d096a2dc>] __insmod_ntfs_S.rodata_L640 [ntfs] 0x35c
[<c0144800>] filldir64 [kernel] 0x0
[<c0126ab4>] do_munmap [kernel] 0x64
[<c0144420>] vfs_readdir [kernel] 0x60
[<c0144800>] filldir64 [kernel] 0x0
[<c014498f>] sys_getdents64 [kernel] 0x4f
[<c0144800>] filldir64 [kernel] 0x0
[<c0106f2b>] system_call [kernel] 0x33


Code: 0f 0b 83 c4 10 83 7d d8 00 75 18 ff 77 24 ff 77 20 68 60 b2

Re: [Linux-NTFS-Dev] NTFS Wirte?

[Richard R. <nt...@fl...>]

Hi Martin,

> So for me NTFS is useless till we can do write with it.

Unfortunately, this is the case for some people.
For others read-only support is useful enough.

> When is it planned?

This is a difficult question.  Read support is inherently easy.
You give the user anything you can understand.

Writing, however, is very difficult.  NTFS is built like a database.
Every piece of information is stored in several places.  If you make
even a simple change you have to know where to write the info.

For example when you rename a file, the name is stored in the MFT
(a large table).  It is also stored in indexes (directories) which
are kept in alphabetical order.  The indexes are kept in a balanced
b+ (binary) tree.  If you change its position then you may need to
rebalance the whole tree.  This is non-trivial.

This means that even the simplest _write_ operations quickly become
very difficult.

Answering your question: only easy bits of writing are supported.
This will change when Anton has time to code it (this is only his hobby)
or we get more help (hint :-).

> Read-only... Maybe that's why it's not in RedHat kernel.

Possibly, but rumours hint at another reason.

Cheers,
  FlatCap (Rich)
  nt...@fl...

[Linux-NTFS-Dev] CFT: NTFS TNG 0.0.2

[Anton A. <ai...@ca...>]

Hi all,

NTFS TNG 0.0.2 release is now available in CVS, module ntfs-driver-tng, 
branch tng-0-0-2. (to check it out use: cvs update -r tng-0-0-2 in your 
ntfs-driver-tng local repository/directory which you can obtain as per 
instructions on the linux-ntfs.sf.net website, then apply the patch in the 
patches directory to your running kernel, recompile and install new kernel 
then compile the ntfs module, install it, and your are all go).

The driver now supports compressed files/directories as well as attribute 
lists (but not yet attribute extents) thus it will work on medium sized 
volumes.

It survives happily the test
         find . -type f -exec md5sum "{}" \;
on my 1.1GiB test partition with over 16k files on it, many of which are 
compressed files/directories.

Please test and report any problems/bugs back to the list. Thanks!

Note that gcc-2.96/3.x or later is required to compile this driver.

Best regards,

         Anton


-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

[Linux-NTFS-Dev] NTFS Wirte?

[Martin P. <mpi...@os...>]

So for me NTFS is useless till we can do write with it.  When is it planned?

Maybe that's why it's not in RedHat kernel.

Thank you.

-- 
Martin Pineault  /* Keep looking for it, soon you will find it. */
OSG Inc.         /* Those who search, will live till the end.   */
mpi...@os...   /* Have we ever met, be gentle and polite.     */
http://www.osginformatique.com  /* Suggestions?  French available.    */

[Linux-NTFS-Dev] NTFS HOWTO

[Richard R. <nt...@fl...>]

I'm losing it, I swear.

http://linux-ntfs.sourceforge.net/info/help.html
http://linux-ntfs.sourceforge.net/info/tech.txt
http://linux-ntfs.sourceforge.net/info/build.txt
http://linux-ntfs.sourceforge.net/info/mount.txt

FlatCap.

[Linux-NTFS-Dev] NTFS HOWTO

[Richard R. <nt...@fl...>]

Hi All,

I finally got around to writing (starting to write) an NTFS HOWTO.
It's basic and incomplete, but it's a start.

It covers three areas so far:

  NTFS Technical questions

    These are only really technical to novices.  There's a set
    of general NTFS questions I haven't yet typed up.  It covers
    how to deal with NTFS as a Win 95/98/ME user.  It makes NO
    reference to Linux.

  How to build the Linux NTFS module

    This refers to a LOT of other sources and should be enough
    for a keen Linux newbie to add NTFS support.

  How to mount an NTFS partition

    More newbie tips on mounting.

I doubt any of this will be new to you all, but it should save me
time answering all the newbie mail I get :-)

Any suggestions, let me know.

Cheers,
    FlatCap (Rich)
    nt...@fl...

Re: [Linux-NTFS-Dev] NTFS module with 2.4.9 kernel?

[Richard R. <nt...@fl...>]

Hi Martin,

Of course, if I wasn't such a [expletive deleted] I'd have told
you where to find the HOWTO I've written :-)

  http://linux-ntfs.sourceforge.net/info/help.html

Enjoy,
  FlatCap (Rich)
  nt...@fl...

Re: [Linux-NTFS-Dev] NTFS module with 2.4.9 kernel?

[Richard R. <nt...@fl...>]

Hi Martin,

> I'm new to it but can't find howto do the module for my 2.4.9-12
> RH 7.1 kernel.

Unfortunately RedHat don't distribute NTFS support.  I don't know why
not.  However they do suppy the kernel source and a .config file which
simplifies building your own kernel.

I've just finished the first draft of an NTFS HOWTO (which mostly points
at other HOWTOs :-), which explains what to do.

Let me know if you have any problems / questions.

FlatCap (Rich)
nt...@fl...

[Linux-NTFS-Dev] NTFS module with 2.4.9 kernel?

[Martin P. <mpi...@os...>]

I'm new to it but can't find howto do the module for my 2.4.9-12 RH 7.1 
kernel.

I've try several thing.

Thank you.

-- 
Martin Pineault  /* Keep looking for it, soon you will find it. */
OSG Inc.         /* Those who search, will live till the end.   */
mpi...@os...   /* Have we ever met, be gentle and polite.     */
http://www.osginformatique.com  /* Suggestions?  French available.    */