On Mon, 31 Oct 2005, Yura Pakhuchiy wrote:
> 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.
Not necessarily. It is not as easy as you ma think. In kernel,
a filesystem's ->truncate _cannot_ return an error as it has a void return
value... I can just disable this at a higer level ->setattr however and
this is probably the solution until truncates are implemented fully, i.e.
I will not allow vmtruncate() to be called on inodes with an attribute
list attribute. This means one will not be able to truncate some more
files than would have been otherwise possible but it would also mean than
an error can be reported to the caller... I thought I had managed to work
around all this in my code but obviously not... )-:
> > 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.
Ah, yes, of course. (-:
> 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).
Ah, cool. I didn't know even Windows did that. (-:
> > 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.
Indeed.
> > > 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,
I have full confidence it will be stable by the time 2.6.15 is released
which is the time it actually matters. The time between full kernel
releases is exactly the time to get things fixed... And "normal" users
never use in-between kernels since they have no idea what a kernel is
never mind how to compile one...
Well, it is not an obvious case at all. It works fine if you stay within
supported cases. My time is very limited and I rely on user testing and
bug reporting to a large extent... I simply did not have a fragmented
file to hand that was not compressed (those do not work as we refuse to
operate on compressed files altogether).
> when I implemented file creation in libntfs, almost no one except
> several persons tested it too.
Yep, such is life. So one publishes the code officially and then people
test it... (-:
> 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.
That is a lame excuse:
1) -mm contains the patch (obviously) as a single file in the split out
directory in Andrew's file space on kernel.org (where you would go to
download the -mm kernel anyway).
2) If you had told me so I could have either posted the patches or put
them somewhere for you... It takes me about 10 seconds to generate them:
cd /usr/src/ntfs-2.6-devel
git format-patch -n <linus' head>
And I get all the patches output to disk...
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
