|
From: Szakacsits S. <sz...@si...> - 2006-11-30 00:55:20
|
On Tue, 28 Nov 2006, Anton Altaparmakov wrote: > On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote: > > > I didn't have time to check the patches yet but wasn't the Vista problem due > > to a bug in libntfs and not because of ntfsresize? > > The problem is that with my first patch which does not turn on unmounting > you end up with an ntfsresize that is horrible: Another ntfsresize design rule was that it doesn't make __ANY__ modification to NTFS until it checked and analyzed the volume and it found to be consistent and safe for resizing. This is very important. It's even explicitely written in the error messages when corrupt volumes are detected which happen relatively often: NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE! The usage of the /f parameter is very IMPORTANT! No modification was and will be made to NTFS by this software until it gets repaired. A lot of softwares, drivers corrupt NTFS and this is a very strong argument for self-protection that it was not ntfsresize which corrupted it because it was already damaged when user wanted to do the resizing. > Please take the time to review the patches... Surely I would but I don't have much free time recently, and unfortunately it doesn't help that seemingly you have checked in your entire private ntfsprogs CVS in one commmit. To be honest, I still can't even see what the problem was. You wrote the journal wasn't emptied. But ntfsresize explicitely does that. Which function became conditional. And perhaps the problem is that that the clean journal detection is broken for Vista. For example, because of journal format change. I have checked the ntfsresize journal reset again, without your latest patches. After the resize: ntfscat -fi 2 /dev/hda1 | hexdump 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 02a04000 So, the journal has been reset, entirely. You say that this is not the case for Vista? Szaka |
