Return-Path: <linux-kernel-owner+willy=40w.ods.org-S1751224AbVJaUtS@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751224AbVJaUtS (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 31 Oct 2005 15:49:18 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751245AbVJaUtS
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 31 Oct 2005 15:49:18 -0500
Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]:39591 "EHLO
	ppsw-9.csi.cam.ac.uk") by vger.kernel.org with ESMTP
	id S1751224AbVJaUtR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 31 Oct 2005 15:49:17 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Date: Mon, 31 Oct 2005 20:49:09 +0000 (GMT)
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: Yura Pakhuchiy <pakhuchiy@gmail.com>
cc: Linus Torvalds <torvalds@osdl.org>, linux-kernel@vger.kernel.org,
       linux-ntfs-dev@lists.sourceforge.net
Subject: Re: [Linux-NTFS-Dev] [2.6-GIT] NTFS: Release 2.1.25.
In-Reply-To: <1130790267.2276.8.camel@localhost>
Message-ID: <Pine.LNX.4.64.0510312040010.10190@hermes-1.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0510311408160.27357@hermes-1.csi.cam.ac.uk>
 <1130790267.2276.8.camel@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4341
Lines: 100

Hi Yura,

On Mon, 31 Oct 2005, Yura Pakhuchiy wrote:
> On Mon, 2005-10-31 at 14:22 +0000, Anton Altaparmakov wrote:
> > And people: please try it before Linus releases 2.6.15 and report back 
> > (especially if you find bugs but even a "it works" would be nice to hear 
> > from a few more people)...
> 
> One more bug, steps to reproduce:
> 1) Create fragmented file with DATA attribute split on several records.
> (using windows or ntfsmount)

That is just evil.  Attribute list attribute is not supported yet!  And 
majority of files are not fragmented like that...

btw. Did you run a chkdsk fter using ntfsmount and before mounting with 
the ntfs driver?  I keep finding that chkdsk finds lots of (minor) 
problems after ntfsmount has written to a drive (I haven't investigated 
since then only times I have done it I was also messing with "strange" 
filenames and things like that so I was not expecting it to necessarily 
work and I haven't had time since to do it again on a clean volume).

Not that that is any excuse for the ntfs driver to crash...  It should 
deal with corruption...

> 2) Overwrite this file with some small (few bytes, but non-zero) file.
> (using kernel driver)

Again, the required truncate is not supported so this cannot work.

> After this cp segfaults on my system and I receive following in dmesg:

Ouch!  It certainly should not do that!  )-:

> NTFS-fs error (device hda4): ntfs_truncate(): Cannot truncate inode 
> 0x169e, attribute type 0x80, because the attribute is highly fragmented 
> (it consists of multiple extents) and this case is not implemented yet.

That is correct.  Attribute list attribute is not supported yet.

> Unable to handle kernel NULL pointer dereference at virtual address 00000029
>  printing eip:
> c01ece9e
> *pde = 00000000
> Oops: 0000 [#1]
> PREEMPT 
> Modules linked in: ltserial ltmodem fglrx vmmon subfs
> CPU:    0
> EIP:    0060:[<c01ece9e>]    Tainted: P      VLI
> EFLAGS: 00010246   (2.6.14-ck1) 
> EIP is at ntfs_prepare_pages_for_non_resident_write+0x4ce/0x1f70
> eax: 00000200   ebx: 00000000   ecx: c78ebcd8   edx: 00000029
> esi: c774e9c4   edi: 00000000   ebp: 00000000   esp: c78ebbec
> ds: 007b   es: 007b   ss: 0068
> Process cp (pid: 2420, threadinfo=c78ea000 task=c9178ad0)
> Stack: c87c1b44 c774e9c4 00000000 ceee43c0 cf596030 c04fd960 00000001 00000000 
>        00000096 00000000 cf603f3c 00000001 c78ebc5c c90bbc54 c78ea000 00000000 
>        00001000 00000000 c90bbc20 09003200 00000000 00000000 00000000 00000000 
> Call Trace:
>  [<c01c40c7>] journal_end+0xa7/0x100
>  [<c01218f1>] current_fs_time+0x51/0x70
>  [<c017d453>] inode_update_time+0xb3/0xe0
>  [<c01f04d6>] ntfs_file_aio_write_nolock+0x216/0x260
>  [<c013f5e1>] __generic_file_aio_read+0x1f1/0x230
>  [<c013f310>] file_read_actor+0x0/0xe0
>  [<c01f06c2>] ntfs_file_writev+0xc2/0x140
>  [<c01320e0>] autoremove_wake_function+0x0/0x60
>  [<c01f0777>] ntfs_file_write+0x37/0x40
>  [<c0160c57>] vfs_write+0xa7/0x180
>  [<c0160e01>] sys_write+0x51/0x80
>  [<c01032e1>] syscall_call+0x7/0xb
> Code: 00 00 00 39 4c 24 74 0f 87 66 ff ff ff 8b 6c 24 58 85 ed 75 69 c7 44 24 5c 00 00 00 00 8b 5c 24 5c 8b b4 24 08 01 00 00 8b 14 9e <8b> 02 f6 c4 08 74 42 8b 52 0c 89 54 24 78 89 d5 89 f6 8b 45 00 

Hmm.  Looks like error handling gone wrong.  Will investigate tomorrow.  
It is osx evening now.

> BTW, great work, but IMHO to early for mainline.

Too late!  (-;  It it there already.  Also it really is not too early!  
Look yourself: you tested it only when I sent it to mainline, you must 
have seen the posts when I asked for testers and also when it was in 
-mm but you didn't test it then.  And I imagine neither did anyone else 
except for me and one other person who reported a bug which I fixed 
prompty...

Thanks for testing and the good bug report!

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/