Corrupt NTFS filesystem after resize

[Magnus Lyckå]

During Hoary preview install, I changed the size of the NTFS partition used by
Win XP (so that Ubuntu would fit) and set up swap and ext3 in the space I got
from that. This led to a working Ubuntu, but Windows XP won't boot any longer. I
get a blue screen with a message that the partition is unbootable (or was it
unmountable?). If I mount the NTFS partition from Ubuntu, things seem ok until I
try to access the directories I really need! :( Then I get I/O error.

xxxx@xxxx:/mnt/c # ls -R > /dev/null
ls: reading directory ./Documents and Settings/All Users/Dokument: Input/output
error
ls: reading directory ./Documents and Settings/All
Users/Start-meny/Program/Databas: Input/output error
etc...

Fdisk says:
Disk /dev/hda: 30.0 GB, 30005821440 bytes
255 heads, 63 sectors/track, 3648 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot Start End Blocks Id System
/dev/hda1 1 7 56196 de Dell Utility
/dev/hda2 * 8 2925 23438835 7 HPFS/NTFS
/dev/hda3 2926 3047 979965 82 Linux swap / Solaris
/dev/hda4 3048 3648 4827532+ 83 Linux

This is a Dell Inspirion 8600C. It has a 30GB disk, and I changed the NTFS size
to 24GB, swap to 1GB and the rest I gave to ext3 /. Before resizing, there was
an unused partition of 7 MB or so in the end of the disk, suggesting that NTFS
possibly wanted some particular granularity of its size.

[Matt Zimmerman (mdz)]

What do you see in the output from 'dmesg' when you get the I/O errors?

Did you run a filesystem check on the NTFS volume recently before resizing it?

[Magnus Lyckå (magnus-thinkware)]

Created an attachment (id=1895)
/var/log/installer/partman

[Magnus Lyckå (magnus-thinkware)]

(In reply to comment #1)
> What do you see in the output from 'dmesg' when you get the I/O errors?

Excerpt follows:
NTFS-fs error (device hda2): ntfs_end_buffer_async_read(): Buffer I/O error,
logical block 56883180.
attempt to access beyond end of device
hda2: rw=0, want=56883182, limit=46877670
NTFS-fs error (device hda2): ntfs_end_buffer_async_read(): Buffer I/O error,
logical block 56883181.
attempt to access beyond end of device
hda2: rw=0, want=56883183, limit=46877670
NTFS-fs error (device hda2): ntfs_end_buffer_async_read(): Buffer I/O error,
logical block 56883182.
attempt to access beyond end of device
hda2: rw=0, want=56883184, limit=46877670
NTFS-fs error (device hda2): ntfs_end_buffer_async_read(): Buffer I/O error,
logical block 56883183.
NTFS-fs error (device hda2): ntfs_readdir(): Reading index allocation data failed.

56883183*512 = 29124189696
46877670*512 = 24001367040

In my layman eyes, this seems to suggest that the resize operation didn't work as
it should. (I assume it should move files in the part of the disk it removes from
the shrunk partition...) It tries to read suff approx 29GB from the beginning (the
original size was something like 29.7 or 29,9GB, and the new size was 24GB).

> Did you run a filesystem check on the NTFS volume recently before resizing it?

It certainly seemed ok in WinXP. I ran the std defragmenter before resizing.
(Before that, the Ubuntu installer reported an all too big minimum size for
the NTFS partition.)

The installer syslog says:
...
Mar 27 15:19:27 main-menu[3124]: (process:18257): parted
Mar 27 15:19:27 main-menu[3124]: (process:18257): md-devices
Mar 27 15:19:27 main-menu[3124]: (process:18257): grep:
Mar 27 15:19:27 main-menu[3124]: (process:18257): /proc/mdstat
Mar 27 15:19:27 main-menu[3124]: (process:18257): : No such file or directory
Mar 27 15:19:27 main-menu[3124]: (process:18257): dump
Mar 27 15:19:27 main-menu[3124]: (process:18257): lvm
Mar 27 15:19:27 main-menu[3124]: (process:18257): File descriptor 3 left open
Mar 27 15:19:27 main-menu[3124]: (process:18257): File descriptor 4 left open
Mar 27 15:19:27 main-menu[3124]: (process:18257): File descriptor 5 left open
Mar 27 15:19:27 main-menu[3124]: (process:18257): File descriptor 6 left open
Mar 27 15:19:27 main-menu[3124]: (process:18257):
Mar 27 15:19:27 main-menu[3124]: (process:18257): No volume groups found
Mar 27 15:19:27 main-menu[3124]: (process:18257):
Mar 27 15:19:27 main-menu[3124]: (process:18257): md
Mar 27 15:19:27 main-menu[3124]: (process:18257): no_media
Mar 27 15:19:27 main-menu[3124]: (process:18257): update_partitions
Mar 27 15:19:27 main-menu[3124]: (process:18257): filesystems_detected
Mar 27 15:19:27 main-menu[3124]: (process:18257): autouse_swap
Mar 27 15:19:27 main-menu[3124]: (process:18257): backup
Mar 27 15:19:27 main-menu[3124]: (process:18257): ntfsresize v1.9.4
Mar 27 15:19:27 main-menu[3124]: (process:18257): NTFS volume version: 3.1
Mar 27 15:19:27 main-menu[3124]: (process:18257): Cluster size : 4096 bytes
Mar 27 15:19:27 main-menu[3124]: (process:18257): Current volume size:
29940015616 bytes (29941 MB)
Mar 27 15:19:27 main-menu[3124]: (process:18257): Current device size:
2994001...

[Colin Watson (cjwatson)]

Could you please have a look through the troubleshooting instructions at
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot and see if any
of that helps?

[Magnus Lyckå (magnus-thinkware)]

(In reply to comment #4)
> Could you please have a look through the troubleshooting instructions at
> http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#troubleshoot and see if any
> of that helps?

root@alytus:/home/mly # ntfsresize -i -n -f /dev/hda2 > x
Segmenteringsfel (core dumped)
root@alytus:/home/mly # more x
ntfsresize v1.9.4
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 24001360384 bytes (24002 MB)
Current device size: 24001367040 bytes (24002 MB)
Checking filesystem consistency ...
  0,00 percent completed

:(

From the page you refer to: "We have intensively tested ntfsresize 1.9.0 before
the stable public release for months and found it just as reliable as the
earlier ntfsresize versions if the precaution instruction was followed: "always
make a test run". Usage is the same as with the older stable versions but please
read carefully and fully its manual page."

I guess the installer needs to make some kind of proper integrity test of the
resized NTFS partition and revert the size change in case of trouble *before*
allowing new partitions to be created (or at least formatted) in the place where
the NTFS partition lived.

[Magnus Lyckå (magnus-thinkware)]

(In reply to comment #5)
> root@alytus:/home/mly # ntfsresize -i -n -f /dev/hda2 > x
> Segmenteringsfel (core dumped)

BTW, without -f (--force) I get:
ERROR: Volume is dirty. Run chkdsk /f and please try again (or see -f option).
(Whatever that means... It's not very helpful if it's a Windows program I'm
supposed to run, since XP thinks the disk is unmountable.)

[Fabio Massimo Di Nitto (fabbione)]

(In reply to comment #6)
> (In reply to comment #5)
> > root@alytus:/home/mly # ntfsresize -i -n -f /dev/hda2 > x
> > Segmenteringsfel (core dumped)
>
> BTW, without -f (--force) I get:
> ERROR: Volume is dirty. Run chkdsk /f and please try again (or see -f option).
> (Whatever that means... It's not very helpful if it's a Windows program I'm
> supposed to run, since XP thinks the disk is unmountable.)
>

Hi, i did try an XP installation, resize the volume and everything was smooth.
At the first boot into XP (after the resize) a chkdsk was run automatically
since XP detected the changes.
Mounting the partition in ubuntu and checked the md5sum of all files reported
no errors or corruption.

Fabio

[Szabolcs Szakacsits (szaka)]

By checking the installer syslog more carefully, I've noticed that udev removed
/dev/hda2 and added them back right during the resize process (between 99.05%
and 99.11%).
The changes done by ntfsresize during that time apparently went to a black
hole, the kernel swallowed them silently.

To me this seems to be a kernel/udev bug. I remember SUSE also had a
similar issue with udev, not too long ago.

This is the only reason I can come up after scratching my head quite hard
for several days and investigating multiply possible other explanations
too.

[Matt Zimmerman (mdz)]

(In reply to comment #8)
> By checking the installer syslog more carefully, I've noticed that udev removed
> /dev/hda2 and added them back right during the resize process (between 99.05%
> and 99.11%).
> The changes done by ntfsresize during that time apparently went to a black
> hole, the kernel swallowed them silently.
>
> To me this seems to be a kernel/udev bug. I remember SUSE also had a
> similar issue with udev, not too long ago.

The fact that udev removes and creates the device node seems like a symptom
rather than the cause; this would indicate that the kernel is generating hotplug
events for the device (and so possibly the device is being removed and recreated
in the kernel).

Do you have any references for the SUSE issue? Perhaps we can learn from their
experience.

[Szabolcs Szakacsits (szaka)]

> The fact that udev removes and creates the device node seems like a
> symptom rather than the cause;

Could you please explain technically how this could be a symptom and
of what? Who and why could generate hotplug events for an internal
disk?

Data are being relocated intensively meanwhile udev removes the
partition. Why? Perhaps a bug or udev config problem.

> Do you have any references for the SUSE issue?

No unfortunately but you could ask udev developers why the
partition is removed when there is an open file descriptor,
_non-stop_ activity on it and the user didn't want to remove
the internal disk during filesystem resizing.

Please note, ntfsresize was written in a way that it can be halted
directly or indirectly any time and the filesystem will still remain
consistent. The only exceptions are power outage (the kernel IO
scheduler is allowed to reorder how the data is written to the disk
for performace reason) and when data is lost/corrupted due to hardware
or kernel problems. The latter seems to be the case here.

[Matt Zimmerman (mdz)]

(In reply to comment #10)
> > The fact that udev removes and creates the device node seems like a
> > symptom rather than the cause;
>
> Could you please explain technically how this could be a symptom and
> of what? Who and why could generate hotplug events for an internal
> disk?

udev responds to hotplug events generated by the kernel. hotplug events are
generated by all sorts of things, and not only for physical devices either.
Notably, hotplug events are generated when the kernel re-reads the partition
table on a block device. If something issued a BLKRRPART ioctl while ntfsresize
was running, for example, it would cause this kind of behaviour (and possibly
corruption as well).

> Data are being relocated intensively meanwhile udev removes the
> partition. Why? Perhaps a bug or udev config problem.

udev manages the device nodes in the filesystem, nothing more. It has nothing
to do with the reading or writing of data from the disk.

[Szabolcs Szakacsits (szaka)]

Ok. Ntfsresize doesn't do any partition table related thing and I can't think
about anything that would have triggered a hotplug event, especially during data
relocation.

I also just realized that ntfsresize was run three times: twice for resizing
during installation and once afterwards for only consistency check (ntfsresize
always starts with a consistency check, it can't be disabled or its result
ignored, not even by option --force).

In the first run it shrunk the filesystem. In the second run it was enlarged
(adjusted to the underlaying partition size). Udev took action during the first
time however the ntfsresize consistency check passed both times (there were no
references to outside of the partition). At the 3rd time (for diagnostic) it
crashed due to undetected, corrupt metadata (Magnus has sent me the core file.
Both the filesystem and the partition sizes are the ones that are expected to be
after the 2nd run. The enlargement is quite simple, only a few metadata are
changed. However the problems are with other data. Data, for those the
consistency checks passed twice earlier and they definitely couldn't be touched
during the 2nd run.

What all these mean?

If the problem is related to udev then everything was kept in memory correctly
(ntfsresize worked fine) but not all the data was written to disk for some
reason (Magnus rightfully noticed that some metadata still refers to its
original place).

An alternative explanation, something corrupted the partition between running
ntfsresize the 2nd and 3rd time.

[Colin Watson (cjwatson)]

One other possibility comes to mind: just before any resize operation, partman
commits any previous partitioning changes to disk. This could certainly involve
partitions being created or removed, which would trigger hotplug events.
Furthermore, sometimes there's an asynchronous delay between hotplug events
being generated and udev getting round to processing the events as device node
changes. So, even though partman runs ntfsresize synchronously, it's possible
that hotplug events left over from the previous commit operation could intervene.

The simplest solution would probably be to call udevstart somewhere in partman's
commit.d scripts.

[Matt Zimmerman (mdz)]

If ntfs is requesting that data be written to disk and it isn't making it, there
is no possible way that udev could be responsible. This would be a kernel or
hardware problem in that case.

I say again: udev is a red herring.

[Szabolcs Szakacsits (szaka)]

(In reply to comment #13)
> So, even though partman runs ntfsresize synchronously, it's possible
> that hotplug events left over from the previous commit operation could intervene.

Good point but could it be that the asynchronous delay is over 3 minutes, as it
seems to be in this case? Or something else is running in parallel that triggers
the event?

Initially I also discussed a possible reason with Magnus. I received a claim some
weeks ago that resizing a hibernated partition can cause problem. Unfortunately I
didn't have time to investigate this case yet deeply but I don't doubt Windows
could
create a mess when it wakes up. However I'm a bit surprised that the consistency
check
can't detect hibernation, though no explicite check implemented for this case
yet. As
a related note, Magnus confirmed that his Windows wasn't hibernated during resizing.

[Szabolcs Szakacsits (szaka)]

Hello!

Magnus, could you please attach or send me the output of

  xxd /mnt/windows/hiberfil.sys | head -12

(you can use 'od -t x2' instead of 'xxd' if it's not installed
by default).

Apparently I could reproduce the problem you have if Windows was
hibernated and I think I've found the way how to detect hibernated
Windows. If these are true then I'll add the needed detection to
ntfsresize as soon as I can (Windows hibernation is very rare,
not the default, suspend/resume the widespread way).

[Magnus Lyckå (magnus-thinkware)]

(In reply to comment #16)

> Magnus, could you please attach or send me the output of
> xxd /mnt/windows/hiberfil.sys | head -12

Only 0000 0000 ...
The first non-null content is at address 0x1000.

[Szabolcs Szakacsits (szaka)]

Then it's indeed wasn't hibernated partition.(In reply to comment #17)
> (In reply to comment #16)
>
> > Magnus, could you please attach or send me the output of
> > xxd /mnt/windows/hiberfil.sys | head -12
>
> Only 0000 0000 ...
> The first non-null content is at address 0x1000.

Then it indeed wasn't hibernated partition.

[Szabolcs Szakacsits (szaka)]

(In reply to comment #18)
>
> Then it indeed wasn't hibernated partition.

Well, unless Windows de-hibernated and reset the file if it were
hibernated before.

[Szabolcs Szakacsits (szaka)]

A followup: some weeks ago I fixed the ntfsresize segfault (caused by
the uniquely corrupt NTFS during filesystem check) and also implemented
hibernation detection (resizing is always refused in these cases). They
are currently available from the Linux-NTFS project's CVS repository but
we plan to make either a new ntfsprogs 2.0.0 or a 1.9.5 maintanence
release or even both, as time permits.

Much else we can't do from the NTFS side since if the problem wasn't
caused by a hibernated partition (what's also a well-known problem for
FAT partitions) then it was due to a bug/feature in another subsystem
explained earlier.

[Matt Zimmerman (mdz)]

Passing to Adam as a windows interop issue...please do some testing and confirm
that NTFS resizing is solid now

[Szabolcs Szakacsits (szaka)]

As I explained earlier in detail, this problem couldn't occur due to ntfsresize
unless Windows was hibernated. In that case Windows indeed destroys the resized,
consistent partition during dehibernation.

The latest ntfsresize version is able to detect hibernated Windows and will
refuse resizing. It also includes several other significant, often asked
enhancements. The major ones are listed here:
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

BTW, I always run my highly diverse and extensive automatic ntfsresize testsuite
which supposed to cover all possible resizing scenarios (many thousands
different cases) before each official releases.

[Adam Conrad (adconrad)]

I can't manage to reproduce any corruption-on-resize problems, but for the sake
of our sanity, perhaps we should consider updating our nfttools to a newer
upstream with the bugfixes mentioned in this bug log.

[Matt Zimmerman (mdz)]

(In reply to comment #23)
> I can't manage to reproduce any corruption-on-resize problems, but for the sake
> of our sanity, perhaps we should consider updating our nfttools to a newer
> upstream with the bugfixes mentioned in this bug log.

Is there a changelog? What are the risk factors?

[Szabolcs Szakacsits (szaka)]

You're beating a dead horse for too long now ... This is not a windows interop
issue, as the log provided above is the clear proof for that. The kernel simply
didn't write out to disk all the changes ntfsresize made. Just think about it.
At that time when this happened you were the first and only one who started to
experiment with a new underlaying storage layer and you were also the only one
who found this "not everything was written to disk" issue (over a hundred
distro/solution ship/use ntfsresize). You must be able to reproduce the problem
without using ntfsresize if the test environment is properly setup and if it
weren't fixed already in the kernel.

Also, ntfsresize is rock solid since its original release, three years ago. The
only problem was if the user resized a hibernated partition. Windows hibernates
in a way that the fs is consistent hence the ntfsresize consistency validation
couldn't catch this without explicite hibernation check.

Full ChangeLog is in the ntfsprogs package (it's not called ntfstools) and the
major changes are also listed at
http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

The chance to destory hibernated Windows is 100% if you don't use the latest
version which have also many important other improvements. Many distro already
use it, SUSE, Mandriva, Debian, etc.

[Matt Zimmerman (mdz)]

(In reply to comment #25)
> You're beating a dead horse for too long now ... This is not a windows interop
> issue, as the log provided above is the clear proof for that. The kernel simply
> didn't write out to disk all the changes ntfsresize made.

This is still pure conjecture on your part; we don't have enough information to
know what happened. We have only one report of the problem and have never been
able to reproduce it. I still haven't seen the relevant kernel messages, but my
best guess is that there was an IDE bus reset or similar hardware-induced event
which happened during the resize.

Magnus, would you attach the complete kernel messages if you still have them?

> Just think about it.
> At that time when this happened you were the first and only one who started to
> experiment with a new underlaying storage layer and you were also the only one
> who found this "not everything was written to disk" issue (over a hundred
> distro/solution ship/use ntfsresize). You must be able to reproduce the problem
> without using ntfsresize if the test environment is properly setup and if it
> weren't fixed already in the kernel.

udev isn't an "underlying storage layer". I've tried to explain this to you
already. udev creates and deletes device nodes in the filesystem, nothing more.
 It does its work entirely in userspace and is not responsible for (e.g.)
performing I/O in the kernel. The "underlying storage layer" in use in this
case was the Linux IDE subsystem, which is not exactly new or experimental.

> Also, ntfsresize is rock solid since its original release, three years ago. The
> only problem was if the user resized a hibernated partition. Windows hibernates
> in a way that the fs is consistent hence the ntfsresize consistency validation
> couldn't catch this without explicite hibernation check.

The user has already stated that hibernation was not in use at the time of the
issue, and so I don't think this is relevant to this bug report. We can
consider updating to a newer ntfsprogs in order to gain this safety check, but
there is no reason to believe that it would help with the problem described
here. It is quite late in our release cycle, and we prefer not to make such
changes without very strong justification.

[Szabolcs Szakacsits (szaka)]

(In reply to comment #26)
> udev isn't an "underlying storage layer".

Indeed and Ubuntu wasn't the first one who used it. So I don't know why you
think I was refering to it. It wasn't the IDE subsystem either and if I
remembered what it was I would name it: I don't use Ubuntu and I don't remember
that new installation setup what I've seen 7 months ago when I checked Ubuntu
out, in about 10 minutes. But perhaps I confuse it with another distro/livecd,
though I doubt it.

[Matt Zimmerman (mdz)]

(In reply to comment #27)
> (In reply to comment #26)
> > udev isn't an "underlying storage layer".
>
> Indeed and Ubuntu wasn't the first one who used it. So I don't know why you
> think I was refering to it.

Because you previously blamed udev for this problem.

> It wasn't the IDE subsystem either and if I
> remembered what it was I would name it: I don't use Ubuntu and I don't remember
> that new installation setup what I've seen 7 months ago when I checked Ubuntu
> out, in about 10 minutes. But perhaps I confuse it with another distro/livecd,
> though I doubt it.

I don't know what you could have meant; Ubuntu hasn't used experimental versions
of any Linux kernel storage subsystem, ever.

[Szabolcs Szakacsits (szaka)]

> (In reply to comment #27)
>> (In reply to comment #26)
>>> udev isn't an "underlying storage layer".
>>
>> Indeed and Ubuntu wasn't the first one who used it. So I don't know why you
>> think I was refering to it.
>
> Because you previously blamed udev for this problem.

I wrote "To me this seems to be a kernel/udev bug" and "If the problem is
related to udev". Troubleshooting and blaming are quite different things.
If the issue was understood and solved then it would be possible to blame
something, not earlier.

Don't stuck at trying to figure out what I think about udev. Forget it.
That's not the important. The important thing is that, the problem was
either Windows related or not. If it was then it's already solved. If it
wasn't then it's still unknown. Going into the Windows interoperability
direction became a waste of time for 4 months now.

I've went over again all logs, comments and emails with Magnus and if
you're interested then I could summarize, when I will have some spare time,
why I think, after all, that the issue was hibernation related.

> I don't know what you could have meant; Ubuntu hasn't used experimental versions
> of any Linux kernel storage subsystem, ever.

I was referring to the minifo overlay filesystem Ubuntu LiveCD uses.
I didn't remember the normal distro doesn't use it. On the page
https://wiki.ubuntu.com/LiveCDDesign there is a comment:
"mini-fo is _BUGGY_."

And yes, in theory it shouldn't have matter related to this bug but the
fields are connected enough, even if very loosely, that an unexpected
interference, bug could cause such problem occasionally (the relocated data
was almost 761 MB which wouldn't have fit into the memory probably).

[Matt Zimmerman (mdz)]

(In reply to comment #29)
> > (In reply to comment #27)

> Don't stuck at trying to figure out what I think about udev. Forget it.
> That's not the important. The important thing is that, the problem was
> either Windows related or not. If it was then it's already solved. If it
> wasn't then it's still unknown. Going into the Windows interoperability
> direction became a waste of time for 4 months now.

Can you explain what you mean by "Going into the Windows interoperability
direction"?

> I've went over again all logs, comments and emails with Magnus and if
> you're interested then I could summarize, when I will have some spare time,
> why I think, after all, that the issue was hibernation related.

It would probably be easier for everyone involved if you would copy your
correspondence here, rather than keeping it private.

> > I don't know what you could have meant; Ubuntu hasn't used experimental versions
> > of any Linux kernel storage subsystem, ever.
>
> I was referring to the minifo overlay filesystem Ubuntu LiveCD uses.

This module was used in the very first release of Ubuntu, and only on the live
CD (which was derived from the current version of Morphix). It has never had
anything to do with the installation, and the Ubuntu live CD has not been used
with Ubuntu for over a year.

Furthermore, minifo worked at the VFS layer, and would not have had any impact
on block devices anyway.

> I didn't remember the normal distro doesn't use it. On the page
> https://wiki.ubuntu.com/LiveCDDesign there is a comment:
> "mini-fo is _BUGGY_."

Yes, it was buggy.

> And yes, in theory it shouldn't have matter related to this bug but the
> fields are connected enough, even if very loosely, that an unexpected
> interference, bug could cause such problem occasionally (the relocated data
> was almost 761 MB which wouldn't have fit into the memory probably).

I can't understand your sentence, but minifo is 100% provably unrelated to this
problem. There is no possible connection whatsoever, since that module was
never on an Ubuntu installation CD, and by the time this report was filed, it
was long since removed from the live CD as well.

[Szabolcs Szakacsits (szaka)]

(In reply to comment #30)
> It would probably be easier for everyone involved if you would copy your
> correspondence here, rather than keeping it private.

You and Colin already got a copy in April which you can share
if Magnus also agrees of course.

In case of doubts, please feel free to send issues upstream. It was great
to work with you! :-)

[Matt Zimmerman (mdz)]

I have only ever received one email from Szaka, which was Message-ID:
<email address hidden>

It contains some quoted text which discusses this problem. It does not contain
the string "hibernat" anywhere, nor does it shed any light on the problem. If
there is additional material which contains the information alluded to in
comment #31.

It does contain another claim from Szaka that this is a udev bug, amusingly.

Since he has decided that he doesn't want to discuss this anymore, this bug has
never been reproducible, and no other users have reported it, its impact seems
not to justify severity 'critical'. Downgrading to major.

Magnus, if you have any additional information, please post it here.

[Szabolcs Szakacsits (szaka)]

(In reply to comment #32)
> I have only ever received one email from Szaka, which was Message-ID:
> <email address hidden>

Right.

> It contains some quoted text which discusses this problem.

Right. I've copied all the relevant parts into Comment #8, back in April.

> It does not contain the string "hibernat" anywhere, nor does it shed any light
on the problem.

Right. All needed information is in this thread, one just needs to put
the puzzle together. It's only you who thought the private emails help.
I've nowhere said so.

> It does contain another claim from Szaka that this is a udev bug, amusingly.

There isn't any udev related comment in that email which I didn't already
copy into Comment #8. You have found again my "To me this seems to be a
kernel/udev bug" comment which is still not claim but speculation,
conjecture.

> Since he has decided that he doesn't want to discuss this anymore,

Absolutely untrue. Actually I've even explicitely asked you in comment #31
that please send the problem reports upstream, to us, developers:

Ad 1. I'll be very busy in the forecoming weeks and others may help you out
earlier (I've already refered to this in comment #29).

Ad 2. You helped me realize that privately helping here is harmful for the
users. See for example in comment #10 that I couldn't help you in the SUSE
issue and also http://blog.andrew.net.au/2005/02/25#upstream

> this bug has never been reproducible, and no other users have reported it,

Unless it was hibernation.

But whatever is the truth, Ubuntu will keep destroying hibernated Windows
(very-very rare) unless it upgrades ntfsprogs.

[Magnus Lyckå (magnus-thinkware)]

(In reply to comment #32)
> Magnus, if you have any additional information, please post it here.

Nope, and I recently reinstalled XP (in a space I don't need to resize)
and wiped the rest of the disk planing to put Ubuntu 05.10 there when it
pops up. (I didn't use the laptop much lately).

I'm really greatful for the efforts that you've all made with this and
the rest of ubuntu, as well as with ntfstools. While I think it's critical
that installing Ubuntu doesn't destroy Windows like this, it certainly
seems like a fairy small problem in real life if it just happened once.

If it was up to me, I'd probably upgrade ntfstools and close this bug report,
but I realize that you're close to a release and that any change implies
work and risks.

[Adam Conrad (adconrad)]

We're shipping ntfsprogs 1.12.1 in dapper now, which should solve these problems.