Re: [Linux-NTFS-Dev] [2.6-GIT] NTFS: Release 2.1.25.

From: Yura Pakhuchiy (pakhuchiy_at_iptel.by)
Date: 10/31/05

  • Next message: Nathan Scott: "Re: [stable] [2.6 patch] fix XFS_QUOTA for modular XFS" 
    To: Anton Altaparmakov <aia21@cam.ac.uk>
Date:	Mon, 31 Oct 2005 23:25:39 +0200

    On Mon, 2005-10-31 at 20:49 +0000, Anton Altaparmakov wrote:
    > 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...

    It seems you forgot to place somewhere "return -EOPNOTSUPP;", if I was
    able to overwrite them.

    > 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).

    Yes, I was forced to do that, because after I received NULL pointer
    dereference first time umount failed and thus dirty bit was on the
    volume.

    BTW, ntfsmount in almost all truncating cases leave absolutely clean
    volume chkdsk happy with, except one case with updating length of
    resident file length in index. About file creation/deletion yes, volume
    sometimes have minor inconsistencies, but windows driver itself often
    leave them (in case file have 2 names, when you change size for one,
    windows does not update another size in index).

    > 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.

    Again, it works, but not in such way as it should.

    > > 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...

    Anyway mainline is not place for unstable code IMHO, or people will
    simply stop trust it. You have test your code better (at least such
    obvious cases), even if no one except you do not want to test it. BTW,
    when I implemented file creation in libntfs, almost no one except
    several persons tested it too.

    About me, I did not tested this code before, at least because you had
    not posted patches to mailing list when you send it to -mm. Sorry, but I
    do not have git repository. 

    -- 
Best regards,
        Yura
-
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/
  • Next message: Nathan Scott: "Re: [stable] [2.6 patch] fix XFS_QUOTA for modular XFS"

    Relevant Pages

    • Re: remap_page_range64() for PPC
      ... and I want to make device registers for our custom ... > This has come up several times on the ppc lists (but since we still ... > call when it goes into mainline. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: arch/xen is a bad idea
      ... I totally agree that merging into i386 could be a long term ... You merge xen hooks in mainline, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Kill signed chars !!! => PPC uses unsigned chars
      ... ints.c:16: warning: comparison is always false due to limited range of data type ... ints are OK BTW. I'm gonna change some of my code to fix this because relying ... Oh and BTW, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Linux 2.6.11.2
      ... > if one of them is a regression. ... diff against mainline shouldn't be patching kernels;-) ... a determanent process by any means;-) ... 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/ ...
      (Linux-Kernel)
    • Re: smp dead lock of io_request_lock/queue_lock patch
      ... > I'm not pushing to necessarily get any of my changes into mainline. ... > people are loath to change core code in mainline, ... > and other interested parties agree on a patch and that patch is widely ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)