Comment 25 for bug 14620

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.