Comment 12 for bug 14620

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.