Comment 26 for bug 14620

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