Debian Bug report logs - #379628
ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: submit@bugs.debian.org

Subject: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 24 Jul 2006 18:00:58 +0200

[Message part 1 (text/plain, inline)]

Package: ntfsprogs
Version: 1.12.1-1
Severity: critical
Justification: causes serious data loss
Tags: d-i

After a resize using Debian Installer of an NTFS partition created with 
Windows Vista Beta 2, I found that the partition was no longer usable.

I have checked that this really is an issue by doing manual resizes of:
- an NTFS (1.2) partition created by installing Windows 2000
- an NTFS (3.1) partition created by installing Windows Vista Beta 2

The two are completely similar, except that the first is successful and 
the second leads to corruption. 

The corruption only becomes clear _after_ the physical partition is 
resized too; resizing the partition back to its original size does not 
get the partition back. ntfsfix does not help either.
Note that during the manual resize operation I used fdisk, but the 
installer uses libparted; the corruption occurs with both.

Logs for the resize of both NTFS partitions are attached and clearly show 
the problem.

I noticed that a 1.13.1 release is available, but cannot tell from the 
changelog if that would fix this issue.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-amd64-generic
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages ntfsprogs depends on:
ii  libc6               2.3.6-15   GNU C Library: Shared libraries
ii  libfuse2            2.5.3-2.1  Filesystem in USErspace library
ii  libntfs8            1.12.1-1   library that provides common NTFS

ntfsprogs recommends no packages.

-- no debconf information

[ntfsresize_Windows2000.log (text/x-log, attachment)]

[ntfsresize_WindowsVista.log (text/x-log, attachment)]

[Message part 4 (application/pgp-signature, inline)]

Message #10 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Subject: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 24 Jul 2006 18:28:03 +0200

[Message part 1 (text/plain, inline)]

After sending the report I noticed that I did not run ntfsfix as root.
Here is the correct output.

debian:~# ntfsfix /dev/sda1
Mounting volume... FAILED
Attempting to correct errors...
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... FAILED
Error setting volume flags.

After running that I _could_ mount the partition, but with the following 
results:
debian:~# mount /dev/sda1 /mnt
debian:~# ls /mnt
ls: reading directory /mnt: Input/output error

dmesg had:
NTFS driver 2.1.25 [Flags: R/W MODULE].
NTFS volume version 1.2.
NTFS-fs warning (device sda1): load_system_files(): Disabling sparse 
support due to NTFS volume version 1.2 (need at least version 3.0).
NTFS-fs error (device sda1): load_system_files(): Volume has unsupported 
flags set.  Mounting read-only.  Run chkdsk and mount in Windows.
NTFS-fs error (device sda1): ntfs_check_logfile(): Did not find any 
restart pages in $LogFile and it was not empty.
NTFS-fs warning (device sda1): load_system_files(): Failed to load 
$LogFile.  Will not be able to remount read-write.  Mount in Windows.
NTFS-fs error (device sda1): ntfs_lookup_inode_by_name(): Directory index 
record with vcn 0x0 is corrupt.  Corrupt inode 0x5.  Run chkdsk.
NTFS-fs error (device sda1): check_windows_hibernation_status(): Failed to 
find inode number for hiberfil.sys.
NTFS-fs warning (device sda1): load_system_files(): Failed to determine if 
Windows is hibernated.  Will not be able to remount read-write.  Run 
chkdsk.
NTFS-fs error (device sda1): ntfs_readdir(): Directory index record with 
vcn 0x0 is corrupt.  Corrupt inode 0x5.  Run chkdsk.

Note that it now reports "NTFS volume version 1.2", while it was 3.1 
before using ntfsresize and ntfsfix.

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 24 Jul 2006 22:43:32 +0200

[Message part 1 (text/plain, inline)]

Thanks for your quick reaction Yuval.

On Monday 24 July 2006 19:42, Yuval Fledel wrote:
> > The two are completely similar, except that the first is successful
> > and the second leads to corruption.
>
> I noticed that the original partition was not the same in both cases.
> example:
> Vista: /dev/sda1   *           1        1217     9775521    7  
> HPFS/NTFS
> 2000:  /dev/sda1   *           1        2550    20482843+   7 
> HPFS/NTFS

No that is not correct (Vista will not even install into less than 16 
MB :-)

From the log:
Current volume size: 20972564992 bytes (20973 MB)
Current device size: 20972568576 bytes (20973 MB)

/dev/sda1   *           1        2550    20481024    7  HPFS/NTFS

That is the same in both cases.

> > The corruption only becomes clear _after_ the physical partition is
> > resized too; resizing the partition back to its original size does
> > not get the partition back. ntfsfix does not help either.
> > Note that during the manual resize operation I used fdisk, but the
> > installer uses libparted; the corruption occurs with both.
>
> If the partition was mountable before changing the physical partition,
> it is most likely that the bug is in the partitionning tool, and not
> in ntfsresize.
>
> I know that Szaka (ntfsresize's author) tested ntfsresize on Windows
> Vista's partitions, and it worked. He is in vocation at the moment and
> can not reply.
>
> Can you check the partitioning again, and this time with sectors as
> unit like ntfsresize states (use the "u" command in fdisk). This one
> is the most common cause for the problem at hand.

Hmm. I did not note anything about that in the FAQ (happy to be proven 
wrong), and it still feels like a regression because with NTFS 1.2 my 
method did work correctly. However, I will give it a try.

It also feels strange because I did not change the starting sector and the 
end sector was well bigger than the new size of the NTFS partition.

Also note that it means that 2 major linux partitioning tools (fdisk and 
parted) would be wrong.

> It is always good to check with the latest version. I'd appriciate if
> you check with 1.13.1 instead of an older version.

Ah, I see 1.13.1 has just hit unstable. I will test with that and let you 
know.

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 379628@bugs.debian.org (full text, mbox, reply):

From: "Yuval Fledel" <yuvalfl@gmail.com>

To: "Frans Pop" <elendil@planet.nl>, 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Tue, 25 Jul 2006 01:25:02 +0200

On 7/24/06, Frans Pop <elendil@planet.nl> wrote:
> Thanks for your quick reaction Yuval.
>
> On Monday 24 July 2006 19:42, Yuval Fledel wrote:
> > > The two are completely similar, except that the first is successful
> > > and the second leads to corruption.
> >
> > I noticed that the original partition was not the same in both cases.
> > example:
> > Vista: /dev/sda1   *           1        1217     9775521    7
> > HPFS/NTFS
> > 2000:  /dev/sda1   *           1        2550    20482843+   7
> > HPFS/NTFS
>
> No that is not correct (Vista will not even install into less than 16
> MB :-)

Sorry, I copied the wrong line for Vista.
/dev/sda1   *           1        2550    20481024    7  HPFS/NTFS

20482843+ is different than 20481024. I know for sure that when I
repartitioned my disk, and entered the same number, only that it
showed with no +, Windows no longer agreed to boot. Returning the
partition table to what it was saved the day.

> It also feels strange because I did not change the starting sector and the
> end sector was well bigger than the new size of the NTFS partition.

When you work with a "cluster" unit, fdisk sometimes move the starting
sector. This is because a cluster may contain several sectors, and the
original starting sector may not be cluster-aligned. When the first
sector moves, the tools and the kernel driver can no longer mount the
partition.

> Ah, I see 1.13.1 has just hit unstable. I will test with that and let you
> know.

Thanks, that would be helpful.

-- 
Yuval Fledel

Message #25 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Tue, 25 Jul 2006 01:44:07 +0200

[Message part 1 (text/plain, inline)]

On Tuesday 25 July 2006 01:25, Yuval Fledel wrote:
> 20482843+ is different than 20481024. I know for sure that when I
> repartitioned my disk, and entered the same number, only that it
> showed with no +, Windows no longer agreed to boot. Returning the
> partition table to what it was saved the day.

Well, these were in both cases (and certainly the Vista case) partitions 
created by the Windows installer itself, and Windows certainly booted 
before resizing. So to me it seems irrelevant for this issue.

[Message part 2 (application/pgp-signature, inline)]

Message #30 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org

Cc: ender@debian.org

Subject: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Tue, 25 Jul 2006 02:12:55 +0200

[Message part 1 (text/plain, inline)]

El lunes, 24 de julio de 2006 18:00, Frans Pop escribió:
> Package: ntfsprogs
> Version: 1.12.1-1
> Severity: critical
> Justification: causes serious data loss
> Tags: d-i
>
> After a resize using Debian Installer of an NTFS partition created with
> Windows Vista Beta 2, I found that the partition was no longer usable.
>
> I have checked that this really is an issue by doing manual resizes of:
> - an NTFS (1.2) partition created by installing Windows 2000
> - an NTFS (3.1) partition created by installing Windows Vista Beta 2
>
> The two are completely similar, except that the first is successful and
> the second leads to corruption.
[...]
> I noticed that a 1.13.1 release is available, but cannot tell from the
> changelog if that would fix this issue.

	Hello, Frans.  Well, I do not have any Vista at reach here at home, but there 
are a couple of them at work, so tomorrow I will test with 1.13.1.  
Nonetheless, 1.12.1 (the version in d-i) was from past October, so there is a 
lot of room for possible improvements in 1.13.1.

	I cannot either tell from the full changelog if there was some fix in this 
release for this issue.

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #35 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Tue, 25 Jul 2006 14:20:57 +0200

[Message part 1 (text/plain, inline)]

severity 379628 important
thanks

Just tested with 1.13.1, but it turns out the problem is not in 
ntfsresize.

The root of the problem seems to be how the Vista installer created 
partitions. Yuval was correct: using default cylinder based partitioning, 
the starting sector _is_ indeed changed from 2048 to 63.

Before deleting/creating the partition:
   /dev/sda1   *           1        2550    20481024    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *        2048    40964095    20481024    7  HPFS/NTFS

After deleting/creating the partition:
   /dev/sda1   *           1        1217     9775521    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *          63    19551104     9775521    7  HPFS/NTFS

After recreating the partition with start sector 2048, the NTFS partition 
was correct.

I would suggest very strongly to document this aspect of resizing an NTFS 
partition better and warn users of this possible cause of data loss.
Neither the upstream FAQ [1] nor the documentation included with the 
package (manpage or /usr/share/doc) currently document this.
Even stronger: the example in the FAQ uses cylinders rather than sectors 
just like I did!
The troubleshooting part of the FAQ does explain about starting sector, 
but does not explain the difference between cylinders based and sector 
based partitioning. Most users will react the same as I did: "but the 
start is still at 1, so that cannot be the problem".

Reducing the severity of this bug report to from RC to important as I feel 
properly documenting this deserves that severity.

With this information, I will try to see if we can fix this issue in the 
Debian Installer. Thank you for helping find the cause of the issue.

Cheers,
FJP

[1] http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: control@bugs.debian.org

Cc: 379628@bugs.debian.org, ender@debian.org

Subject: Frans forgot to send the mail to control@b.d.o.

Date: Tue, 25 Jul 2006 15:50:31 +0200

[Message part 1 (text/plain, inline)]

severity 379628 important
thanks for the fish

	Now the severity is correct.


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #47 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: control@bugs.debian.org, 379628@bugs.debian.org

Cc: debian-boot@lists.debian.org

Subject: clone #379628 to debian installer

Date: Tue, 25 Jul 2006 21:35:05 +0200

[Message part 1 (text/plain, inline)]

clone 379628 -1
reassign -1 partman-partitioning 40
retitle -1 NTFS (partition) not recreated correctly after resize:incorrect start sector
severity -1 grave
tags -1 - d-i
thanks

As can be seen in the bug history, partman needs to create the new
smaller/larger partition with the same start sector (not start cylinder)
as the old partition.

Although this problem has now manifested itself with NTFS partitions, it
is not unthinkable that this is actually potential problem for other
file systems as well.

[Message part 2 (application/pgp-signature, inline)]

Message #54 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, control@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Sun, 13 Aug 2006 21:53:43 +0200

[Message part 1 (text/plain, inline)]

severity 379628 grave
thanks

Hello again,

I'm afraid I have to upgrade this bug back to grave...
I've further researched and tested the resize problem and I've come to the 
conclusion that there are two issues:
1) the change in the start partition by libparted, now detailed in
   http://bugs.debian.org/380226;
2) some kind of corruption inside the NTFS partition, probably by
   ntfsresize even if the 1st issue is avoided.

I'll explain the 2nd issue in more detail below.

I've reinstalled Windows Vista Beta 2 into a 20 GB partition (first 
partition of the disk), same as I did in my earlier attempts.

I reinstalled grub to the MBR and afterwards checked that Vista still 
booted OK.

Then I have resized the partition from an installed Debian unstable system 
(i.e. not from Debian Installer).
- ntfsresize -i /dev/sda1
- ntfsresize -s 9G /dev/sda1    # Shrink the partition to 9GB
- ntfsresize -i -f /dev/sda1
- Use fdisk in "sector" mode to resize the partition to ~10GB.
  Old start/end sectors: 2048 - 40964095; type NTFS, boot flag set
  New start/end sectors: 2048 - 20482047; type NTFS, boot flag set
- Reboot the system to let Linux know the new partition table
- ntfsresize -i -f /dev/sda1
- ntfsresize -f /dev/sda1       # Grow the partition to the size of the
                                # physical partition (~ 10GB)
- ntfsresize -i -f /dev/sda1

All ntfsresize commands were completely successful.

Next I tried to reboot into Vista:
- The initial stage of the boot is OK: I get the first graphical screen
  with a little endlessly moving "progress" bar and the copyright info
  below it.
- After a little while there is no disk activity anymore and the system
  no longer responds to anything (not even ctrl-alt-del); the "progress"
  bar keeps on moving though.

After a cold reset, I boot Vista again and get the option to select "Safe 
mode with command prompt" (from which I conclude that Vista must have 
registered the previous attempt as failed):
- I get a text screen with "Loading windows files" at the top as title
  and "Please wait..." at the bottom as status.
- I see a fair number of files being loaded, but at some point that just
  stops and the system is frozen again. The last files that have been
  loaded are:
     Loaded: \Windows\system32\Drivers\Mup.sys
     Loaded: \Windows\system32\drivers\ecache.sys
     Loaded: \Windows\system32\DRIVERS\fevol.sys
     Loaded: \Windows\system32\Drivers\disk.sys
     Loaded: \Windows\system32\drivers\CLASSPNP.sys
     Loaded: \Windows\system32\drivers\crcdisk.sys

Note the changing case of the "drivers" directory, but that could just be 
how they are listed somewhere.

I think that the problem in both boots is exactly the same. It is just 
that with the safe boot what happens is more visible.

Cheers,
Frans Pop

[Message part 2 (application/pgp-signature, inline)]

Message #59 received at 379628@bugs.debian.org (full text, mbox, reply):

From: "Gary L. Greene Jr." <greeneg@phoenuxos.com>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Sun, 13 Aug 2006 16:14:37 -0400

[Message part 1 (text/plain, inline)]

On Sunday 13 August 2006 15:53, Frans Pop wrote:
> severity 379628 grave
> thanks
>
> Hello again,
>
> I'm afraid I have to upgrade this bug back to grave...
> I've further researched and tested the resize problem and I've come to the
> conclusion that there are two issues:
> 1) the change in the start partition by libparted, now detailed in
>    http://bugs.debian.org/380226;
> 2) some kind of corruption inside the NTFS partition, probably by
>    ntfsresize even if the 1st issue is avoided.
>
> I'll explain the 2nd issue in more detail below.
>
> I've reinstalled Windows Vista Beta 2 into a 20 GB partition (first
> partition of the disk), same as I did in my earlier attempts.
>
> I reinstalled grub to the MBR and afterwards checked that Vista still
> booted OK.
>
> Then I have resized the partition from an installed Debian unstable system
> (i.e. not from Debian Installer).
> - ntfsresize -i /dev/sda1
> - ntfsresize -s 9G /dev/sda1    # Shrink the partition to 9GB
> - ntfsresize -i -f /dev/sda1
> - Use fdisk in "sector" mode to resize the partition to ~10GB.
>   Old start/end sectors: 2048 - 40964095; type NTFS, boot flag set
>   New start/end sectors: 2048 - 20482047; type NTFS, boot flag set
> - Reboot the system to let Linux know the new partition table
> - ntfsresize -i -f /dev/sda1
> - ntfsresize -f /dev/sda1       # Grow the partition to the size of the
>                                 # physical partition (~ 10GB)
> - ntfsresize -i -f /dev/sda1
>
> All ntfsresize commands were completely successful.
>
> Next I tried to reboot into Vista:
> - The initial stage of the boot is OK: I get the first graphical screen
>   with a little endlessly moving "progress" bar and the copyright info
>   below it.
> - After a little while there is no disk activity anymore and the system
>   no longer responds to anything (not even ctrl-alt-del); the "progress"
>   bar keeps on moving though.
>
> After a cold reset, I boot Vista again and get the option to select "Safe
> mode with command prompt" (from which I conclude that Vista must have
> registered the previous attempt as failed):
> - I get a text screen with "Loading windows files" at the top as title
>   and "Please wait..." at the bottom as status.
> - I see a fair number of files being loaded, but at some point that just
>   stops and the system is frozen again. The last files that have been
>   loaded are:
>      Loaded: \Windows\system32\Drivers\Mup.sys
>      Loaded: \Windows\system32\drivers\ecache.sys
>      Loaded: \Windows\system32\DRIVERS\fevol.sys
>      Loaded: \Windows\system32\Drivers\disk.sys
>      Loaded: \Windows\system32\drivers\CLASSPNP.sys
>      Loaded: \Windows\system32\drivers\crcdisk.sys
>
> Note the changing case of the "drivers" directory, but that could just be
> how they are listed somewhere.

The listed output from safe mode load isn't related at all, as the system uses 
entries in the registry to get that information, and since NTFS is case 
insensitive, some driver manufacturers list the reg entry to be in uppercase.

> I think that the problem in both boots is exactly the same. It is just
> that with the safe boot what happens is more visible.
>
> Cheers,
> Frans Pop

[Message part 2 (application/pgp-signature, inline)]

Message #66 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Cc: control@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Sun, 13 Aug 2006 23:18:08 +0300 (MET DST)

Hi,

Sorry, I was away and didn't have time yet to answer your former ntfsresize 
emails (afair, you also found the solution yourself which is in the manual 
and at end of the ntfsresize output).

On Sun, 13 Aug 2006, Frans Pop wrote:

> - Use fdisk in "sector" mode to resize the partition to ~10GB.
>   Old start/end sectors: 2048 - 40964095; type NTFS, boot flag set
>   New start/end sectors: 2048 - 20482047; type NTFS, boot flag set

fdisk can also corrupt the partition table which results the behavior you 
described. Though it doesn't happen so often as with parted.

I seriously suggest to investigate the partition table changes from byte to 
byte and set exactly what Vista expects or which worked before 

You can also safely reboot into Vista after ntfsresize, no need to do the 
partitioning at the same time. If Vista boots then it's not ntfsresize 
problem, if it doesn't then it's ntfsresize problem.

So far there were only positive feedbacks using ntfsresize with Vista (it 
started to included a built-in ntfs resizer but it corrupts ntfs, so people 
still use ntfsresize instead). If there were some problem with ntfsresize 
on Vista then we should hear much more similar reports.

	Szaka

Message #73 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 15:55:06 +0200

[Message part 1 (text/plain, inline)]

> You can also safely reboot into Vista after ntfsresize, no need to do
> the partitioning at the same time. If Vista boots then it's not
> ntfsresize problem, if it doesn't then it's ntfsresize problem.

I'm sorry, but I get exactly the same error if I do not run fdisk to 
change the partition size but only run ntfsresize.

Of course, it could also be a bug in the version of Vista I'm using...
(Beta 2; build 5384, updated with available updates)

Cheers,
FJP

P.S. I'll be on holiday for the next two weeks.

[Message part 2 (application/pgp-signature, inline)]

Message #78 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 16:40:49 +0200 (MEST)

On Mon, 21 Aug 2006, Frans Pop wrote:

> > You can also safely reboot into Vista after ntfsresize, no need to do
> > the partitioning at the same time. If Vista boots then it's not
> > ntfsresize problem, if it doesn't then it's ntfsresize problem.
> 
> I'm sorry, but I get exactly the same error if I do not run fdisk to 
> change the partition size but only run ntfsresize.

Excellent, thanks! The next test would be to checksum each file before and
after resizing.

If a checksum doesn't match (except a few metadata files) then you've found an
ntfsresize problem. 

If the checksums match for each files then it's quite probably a Vista problem
Microsoft is interested to hear about: currently they are facing fines due to
executing anti-competitive business and must pay 3 million US$ a day. More
evidence about they keep breaking interoperability doesn't sound very good for
them.
 
> P.S. I'll be on holiday for the next two weeks.

Thanks and have a nice vacation! 

I'd also like to encourage everybody to try to figure out the above, if they
have the possibility to do so (I have only vista metadata images at present).

	Szaka

Message #83 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 16:46:58 +0200 (MEST)

On Mon, 21 Aug 2006, Szakacsits Szabolcs wrote:
> On Mon, 21 Aug 2006, Frans Pop wrote:
> 
> > > You can also safely reboot into Vista after ntfsresize, no need to do
> > > the partitioning at the same time. If Vista boots then it's not
> > > ntfsresize problem, if it doesn't then it's ntfsresize problem.
> > 
> > I'm sorry, but I get exactly the same error if I do not run fdisk to 
> > change the partition size but only run ntfsresize.

Btw, seemingly you're using ntfsprogs 1.12.1. Can you reproduce this with
1.13.1 as well? Though there shouldn't be any difference in the outcome,
whatever is the ntfsresize version.

	Szaka
 
> Excellent, thanks! The next test would be to checksum each file before and
> after resizing.
> 
> If a checksum doesn't match (except a few metadata files) then you've found an
> ntfsresize problem. 
> 
> If the checksums match for each files then it's quite probably a Vista problem
> Microsoft is interested to hear about: currently they are facing fines due to
> executing anti-competitive business and must pay 3 million US$ a day. More
> evidence about they keep breaking interoperability doesn't sound very good for
> them.
>  
> > P.S. I'll be on holiday for the next two weeks.
> 
> Thanks and have a nice vacation! 
> 
> I'd also like to encourage everybody to try to figure out the above, if they
> have the possibility to do so (I have only vista metadata images at present).
> 
> 	Szaka
> 
> 

Message #88 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 17:06:09 +0200 (MEST)

On Mon, 21 Aug 2006, Szakacsits Szabolcs wrote:
> On Mon, 21 Aug 2006, Szakacsits Szabolcs wrote:
> > On Mon, 21 Aug 2006, Frans Pop wrote:
> > 
> > > > You can also safely reboot into Vista after ntfsresize, no need to do
> > > > the partitioning at the same time. If Vista boots then it's not
> > > > ntfsresize problem, if it doesn't then it's ntfsresize problem.
> > > 
> > > I'm sorry, but I get exactly the same error if I do not run fdisk to 
> > > change the partition size but only run ntfsresize.
> 
> Btw, seemingly you're using ntfsprogs 1.12.1. Can you reproduce this with
> 1.13.1 as well? Though there shouldn't be any difference in the outcome,
> whatever is the ntfsresize version.

I just noticed that apparently you use vmware. Do you have this problem also
on real computers? Because it's a bit strange that ntfsresize worked with
vista so far. So the problem may be in vmware, not vista or ntfsresize.

	Szaka

> > Excellent, thanks! The next test would be to checksum each file before and
> > after resizing.
> > 
> > If a checksum doesn't match (except a few metadata files) then you've found an
> > ntfsresize problem. 
> > 
> > If the checksums match for each files then it's quite probably a Vista problem
> > Microsoft is interested to hear about: currently they are facing fines due to
> > executing anti-competitive business and must pay 3 million US$ a day. More
> > evidence about they keep breaking interoperability doesn't sound very good for
> > them.
> >  
> > > P.S. I'll be on holiday for the next two weeks.
> > 
> > Thanks and have a nice vacation! 
> > 
> > I'd also like to encourage everybody to try to figure out the above, if they
> > have the possibility to do so (I have only vista metadata images at present).
> > 
> > 	Szaka
> > 
> > 
> 
> 

Message #93 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 17:42:04 +0200

[Message part 1 (text/plain, inline)]

On Monday 21 August 2006 17:06, Szakacsits Szabolcs wrote:
> Btw, seemingly you're using ntfsprogs 1.12.1. Can you reproduce this
> with 1.13.1 as well? Though there shouldn't be any difference in the
> outcome, whatever is the ntfsresize version.

Yes, I have done previous tests using 1.13.1 too, indeed with no 
difference in behavior. I have just upgraded my test system from etch to 
sid, so all my following tests will use 1.13.1 again.

> I just noticed that apparently you use vmware. Do you have this problem
> also on real computers? Because it's a bit strange that ntfsresize
> worked with vista so far. So the problem may be in vmware, not vista or
> ntfsresize.

Yes, all my previous tests have been on real hardware (an em64t box).
I have just switched to vmware so I don't have to reinstall Vista every 
time when I need to go back (which takes *way* to long...). The issue and 
behavior is identical.
This also confirms that the issue is not 32-bit / 64-bit related and in 
vmware I'm running i386.

[Message part 2 (application/pgp-signature, inline)]

Message #98 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 18:02:51 +0200 (MEST)

On Mon, 21 Aug 2006, Frans Pop wrote:
>
> Yes, I have done previous tests using 1.13.1 too, indeed with no 
> difference in behavior. I have just upgraded my test system from etch to 
> sid, so all my following tests will use 1.13.1 again.

Ok, thanks.
 
> Yes, all my previous tests have been on real hardware (an em64t box).
> I have just switched to vmware so I don't have to reinstall Vista every 
> time when I need to go back (which takes *way* to long...). 

You may use ntfsclone. It makes an exact copy (clone) and installs about at
the maxumim disk speed. But yes, vmware snapshotting must be much faster ;)

> The issue and behavior is identical. This also confirms that the issue is
> not 32-bit / 64-bit related and in vmware I'm running i386.

Interesting. Vista beta NTFS has a few new features but everything should be
backward compatible.

I've seen one of your Vista logs, when ntfsresize couldn't open the volume
anymore after a reboot to Vista. This could mean that Vista didn't notice that
the volume size has changed and it messed up the NTFS itself. In the past the
same could happen if hibernated Windows was resized, until we added the
detection.

	Szaka

Message #103 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 17:15:42 +0100

On Mon, 2006-08-21 at 18:02 +0200, Szakacsits Szabolcs wrote:
> On Mon, 21 Aug 2006, Frans Pop wrote:
> >
> > Yes, I have done previous tests using 1.13.1 too, indeed with no 
> > difference in behavior. I have just upgraded my test system from etch to 
> > sid, so all my following tests will use 1.13.1 again.
> 
> Ok, thanks.
>  
> > Yes, all my previous tests have been on real hardware (an em64t box).
> > I have just switched to vmware so I don't have to reinstall Vista every 
> > time when I need to go back (which takes *way* to long...). 
> 
> You may use ntfsclone. It makes an exact copy (clone) and installs about at
> the maxumim disk speed. But yes, vmware snapshotting must be much faster ;)
> 
> > The issue and behavior is identical. This also confirms that the issue is
> > not 32-bit / 64-bit related and in vmware I'm running i386.
> 
> Interesting. Vista beta NTFS has a few new features but everything should be
> backward compatible.
> 
> I've seen one of your Vista logs, when ntfsresize couldn't open the volume
> anymore after a reboot to Vista. This could mean that Vista didn't notice that
> the volume size has changed and it messed up the NTFS itself. In the past the
> same could happen if hibernated Windows was resized, until we added the
> detection.

Interesting point.  I wonder if this is some kind of "boot cache" like
mechanism based on disk blocks to accelerate Vista startup.  Thus when
ntfsresize moves things around the "boot cache" file becomes effectively
corrupt and Vista cannot start...  Just a thought...

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://www.linux-ntfs.org/ & http://www-stu.christs.cam.ac.uk/~aia21/

Message #108 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: linux-ntfs-dev@lists.sf.net

Cc: 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 18:17:46 +0200

[Message part 1 (text/plain, inline)]

On Monday 21 August 2006 16:40, Szakacsits Szabolcs wrote:
> If a checksum doesn't match (except a few metadata files) then you've
> found an ntfsresize problem.

Attached is the result of the md5sum check straight after running 
ntfsresize (failures only).

Let me know if you want the files for comparison.

[vista.md5.FAILED (text/plain, attachment)]

[Message part 3 (application/pgp-signature, inline)]

Message #113 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: linux-ntfs-dev@lists.sf.net, 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 20:31:24 +0300 (MET DST)

On Mon, 21 Aug 2006, Frans Pop wrote:
> On Monday 21 August 2006 16:40, Szakacsits Szabolcs wrote:
> > If a checksum doesn't match (except a few metadata files) then you've
> > found an ntfsresize problem.
> 
> Attached is the result of the md5sum check straight after running 
> ntfsresize (failures only).
> 
> Let me know if you want the files for comparison.

Would it be possible to send the vista metadata image according to

 http://wiki.linux-ntfs.org/doku.php?id=ntfsclone#store_only_ntfs_metadata

and tell us at what size you resize? Thanks.

	Szaka

Message #118 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: linux-ntfs-dev@lists.sf.net, 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 20:33:04 +0300 (MET DST)

On Mon, 21 Aug 2006, Szakacsits Szabolcs wrote:
> On Mon, 21 Aug 2006, Frans Pop wrote:
> > On Monday 21 August 2006 16:40, Szakacsits Szabolcs wrote:
> > > If a checksum doesn't match (except a few metadata files) then you've
> > > found an ntfsresize problem.
> > 
> > Attached is the result of the md5sum check straight after running 
> > ntfsresize (failures only).
> > 
> > Let me know if you want the files for comparison.
> 
> Would it be possible to send the vista metadata image according to

I've meant the image before resizing.

	Szaka

>  http://wiki.linux-ntfs.org/doku.php?id=ntfsclone#store_only_ntfs_metadata
> 
> and tell us at what size you resize? Thanks.

Message #123 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: linux-ntfs-dev@lists.sf.net, 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 20:46:59 +0300 (MET DST)

On Mon, 21 Aug 2006, Frans Pop wrote:
> On Monday 21 August 2006 16:40, Szakacsits Szabolcs wrote:
> > If a checksum doesn't match (except a few metadata files) then you've
> > found an ntfsresize problem.
> 
> Attached is the result of the md5sum check straight after running 
> ntfsresize (failures only).

Just some quick questions: do you always used the same hardware/disk? Are 
the files the same for which the checksums differ if you resize again at 
the exact same size? 

	Szaka

Message #128 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 20:59:24 +0200

[Message part 1 (text/plain, inline)]

On Monday 21 August 2006 19:31, you wrote:
> Would it be possible to send the vista metadata image

Available from: http://people.debian.org/~fjp/ntfsmeta.img.bz2

> and tell us at what size you resize? Thanks.

Mostly at 9GB but 12GB also fails.

> Just some quick questions: do you always used the same hardware/disk?

Yes. The tests on real hardware were all on one machine and the ones in 
VMWare I've repeated in the same virtual machine (two times from 
scratch).

> Are the files the same for which the checksums differ if you resize
> again at the exact same size?

If I try that with -f option, I get "Nothing to do: NTFS volume size is 
already OK."

I tried resizing from 9->10 => "failed" files unchanged
followed by resizing from 10->8 => "failed" files unchanged.
Full check of all files again => same 4 failed, no new failed files.

Or do you mean for me to retry again starting from the situation _before_ 
resizing?

BTW, I did the md5sums with '-b' option.

[Message part 2 (application/pgp-signature, inline)]

Message #133 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 22:10:45 +0300 (MET DST)

On Mon, 21 Aug 2006, Frans Pop wrote:
> > Are the files the same for which the checksums differ if you resize
> > again at the exact same size?
> 
> Or do you mean for me to retry again starting from the situation _before_ 
> resizing?

Yes. If it's repeatable then we could exclude that you have a hardware 
problem with random data corruptions (disk, cable, memory, etc). Similar 
happened before.

	Szaka

Message #138 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 22:32:41 +0300 (MET DST)

On Mon, 21 Aug 2006, Frans Pop wrote:
> On Monday 21 August 2006 19:31, you wrote:
> > Would it be possible to send the vista metadata image
> 
> Available from: http://people.debian.org/~fjp/ntfsmeta.img.bz2
> 
> > and tell us at what size you resize? Thanks.
> 
> Mostly at 9GB but 12GB also fails.

Resizing at 12 GB doesn't require any relocation:

    # ntfsresize -ns 12G vista-corruptions.img
    ntfsresize v1.3.1 (libntfs 9:0:0)
    Device name        : vista-corruptions.img
    NTFS volume version: 3.1
    Cluster size       : 4096 bytes
    Current volume size: 20971516416 bytes (20972 MB)
    Current device size: 20971516416 bytes (20972 MB)
    New volume size    : 11999994368 bytes (12000 MB)
    Checking filesystem consistency ...
    100.00 percent completed
    Accounting clusters ...
    Space in use       : 7052 MB (33.6%)
    Collecting resizing constraints ...
==> Needed relocations : 0 (0 MB)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Schedule chkdsk for NTFS consistency check at Windows boot time ...
    Resetting $LogFile ... (this might take a while)
    Updating $BadClust file ...
    Updating $Bitmap file ...
    Updating Boot record ...
    The read-only test run ended successfully.

So files can't become corrupted.

	Szaka

Message #143 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Mon, 21 Aug 2006 23:03:34 +0300 (MET DST)

On Mon, 21 Aug 2006, Szakacsits Szabolcs wrote:
> On Mon, 21 Aug 2006, Frans Pop wrote:
> > On Monday 21 August 2006 19:31, you wrote:
> > > Would it be possible to send the vista metadata image
> > 
> > Available from: http://people.debian.org/~fjp/ntfsmeta.img.bz2
> > 
> > > and tell us at what size you resize? Thanks.
> > 
> > Mostly at 9GB but 12GB also fails.
> 
> Resizing at 12 GB doesn't require any relocation:
> 
>     # ntfsresize -ns 12G vista-corruptions.img
>     ntfsresize v1.3.1 (libntfs 9:0:0)
>     Device name        : vista-corruptions.img
>     NTFS volume version: 3.1
>     Cluster size       : 4096 bytes
>     Current volume size: 20971516416 bytes (20972 MB)
>     Current device size: 20971516416 bytes (20972 MB)
>     New volume size    : 11999994368 bytes (12000 MB)
>     Checking filesystem consistency ...
>     100.00 percent completed
>     Accounting clusters ...
>     Space in use       : 7052 MB (33.6%)
>     Collecting resizing constraints ...
> ==> Needed relocations : 0 (0 MB)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     Schedule chkdsk for NTFS consistency check at Windows boot time ...
>     Resetting $LogFile ... (this might take a while)
>     Updating $BadClust file ...
>     Updating $Bitmap file ...
>     Updating Boot record ...
>     The read-only test run ended successfully.
> 
> So files can't become corrupted.

And resizing at 9 GB, only one file problematic file gets relocated, the 
other three aren't touched. 

If files would get randomly corrupted then the regression tests should 
catch them, and also more people would report file corruptions. 

I think you have a hardware problem.

	Szaka

Message #148 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Tue, 22 Aug 2006 01:10:07 +0200

[Message part 1 (text/plain, inline)]

On Monday 21 August 2006 21:10, you wrote:
> Yes. If it's repeatable then we could exclude that you have a hardware
> problem with random data corruptions (disk, cable, memory, etc).
> Similar happened before.

Looks like I made a mistake somehow while _creating_ the md5sum file.
It turns out the files are actually unchanged. I'm not sure what I've done 
wrong, but the following leads me to conclude this was a false lead:
- after restoring the vmware image _before resize_, the files that were
  "changed" failed a full md5sums check too and their md5sums were
  actually the same as those I got _after_ resizing;
- rebooting this restored vmware image into Vista led to a succesful
  boot;
- I restored again and created a new md5sum file; comparing that with the
  original file only showed differences for the 4 files, as expected;
- resizing to both 9G and 12G results in exactly the same issue I've
  been seeing since the beginning when rebooting into Vista;
  (thanks for pointing out that no relocation takes place for 12G; I'm
  slowly starting to understand what is actually happening);
- checking the md5sums against the newly created check file results in
  _no_ differences.

So we're back to the previous state: ntfsresize seems to work fine; the 
partition can be mounted fine in linux (though flagged dirty), but it 
completely reproducible fails to reboot in exactly the same way on both:
- em64t real hardware after resizing from 64-bits linux;
- within vmware running 32-bits linux (run on a different box from the
  previous tests).

On Monday 21 August 2006 22:03, you wrote:
> I think you have a hardware problem.

No, I think that is too easy given the above. Please allow for the fact 
that testing this involves some serious juggling and a small mistake is 
easily made.

I think (not hindered by any real knowledge) there are several options.
- The version of Vista that I happen to have has a bug which is not
  present in other (earlier/later, I don't know...) versions.
- Microsoft has subtly changed the way in which ntfs metadata is expected
  to be for a "dirty" filesystem.
  Where do changes for these actions end up?
  >  Schedule chkdsk for NTFS consistency check at Windows boot time ...
  >  Resetting $LogFile ... (this might take a while)
  >  Updating $BadClust file ...
  >  Updating $Bitmap file ...
  >  Updating Boot record ...
- Microsoft has put something sneaky in the boot procedure.
- Microsoft does something sneaky in the sectors between 63 and 2048 it
  does not use while creating the NTFS partition.

I checked MBR and partition table, but these are unchanged after the 
resize.

This is the last I can do for now. From now on I'm going into holiday 
mode.

The next thing to do is probably for other people to actively try to 
reproduce what I am seeing, actually installing and resizing Vista 
(preferably Beta2).

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #153 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: debian-release@lists.debian.org, control@bugs.debian.org

Cc: 379835@bugs.debian.org, 380226@bugs.debian.org, 379628@bugs.debian.org

Subject: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important

Date: Thu, 12 Oct 2006 07:59:34 +0200

[Message part 1 (text/plain, inline)]

severity 379835 important
thanks

There are currently three RC bugs open related to the resizing of NTFS 3.1 
partitions as created by Windows Vista.

- #379628: ntfsresize - upstream bug, but disputed; I can reproduce it
           reliably though; needs confirmation by someone else
- #380226: libparted - clear issue, recently further traced during BSP in
           Utrecht; needs attention from Debian maintainer and upstream
- #379835: partman - no bug in partman itself, but the result of the two
           listed above (blocked by both)

I have today uploaded a version of partman-partitioning that includes a 
check for NTFS 3.1 partitions and refuses to resize in that case; earlier 
NTFS partitions (NT, XP, 2000) should still be resizable.
As partman is now "safe" I am downgrading #379835 to important.

For #380226 I recommend tagging it 'etch-ignore'. 
The reason I think it's safe to do that is that it may only manifest 
itself in the installer. I'm unsure where else and how libparted is used 
though.
I have tried resizing an NTFS 3.1 partition using parted, and that 
correctly left the starting partition unchanged, so parted is unaffected.

IMO #379628 should not be ignored for Etch and it would be nice if someone 
else would try to either reproduce the bug or prove me wrong. There is 
plenty of information in the BR for that. Without a working ntfsresize, 
resizing NTFS 3.1 partitions is a no-op anyway.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #158 received at 379628@bugs.debian.org (full text, mbox, reply):

From: "Yuval Fledel" <yuvalfl@gmail.com>

To: "Frans Pop" <elendil@planet.nl>, 379628@bugs.debian.org

Subject: Re: Bug#379628: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important

Date: Thu, 12 Oct 2006 12:05:05 +0200

On 10/12/06, Frans Pop wrote:
> There are currently three RC bugs open related to the resizing of NTFS 3.1
> partitions as created by Windows Vista.
>
> - #379628: ntfsresize - upstream bug, but disputed; I can reproduce it
>            reliably though; needs confirmation by someone else
[...]
> I have today uploaded a version of partman-partitioning that includes a
> check for NTFS 3.1 partitions and refuses to resize in that case; earlier
> NTFS partitions (NT, XP, 2000) should still be resizable.

XP use NTFS 3.1 too. You've just blocked resizing of most users' NTFS
partitions.

> IMO #379628 should not be ignored for Etch and it would be nice if someone
> else would try to either reproduce the bug or prove me wrong. There is
> plenty of information in the BR for that. Without a working ntfsresize,
> resizing NTFS 3.1 partitions is a no-op anyway.

I've done some web searching and I have a wild guess about pcmcia.sys.

After resizing, please boot into Vista's install disk and into the
recovery console. From there, rename "system32\drivers\pcmcia.sys"
(e.g. to "pcmcia.bak") and reboot. Does Vista now boots? What about
Safe mode?

Another solution I found on the net was for Win2003 and was replacing
"ntldr" and "ntdetect.com" with the ones on the install disk. The best
projection on a newly installed Vista would be to replace the files
with files from Win2003 or XP. Does this solve the case?

If any of the above two workarounds help, then this is clearly an MS
bug and should be fixed in Vista. Only if Vista final does not fix it,
we can add a workaround to ntfsresize by checking the MD5 of the
relevant files.

Thanks

> Cheers,
> FJP

-- 
Yuval Fledel

Message #163 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Subject: Re: Bug#379628: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important

Date: Sat, 28 Oct 2006 03:30:53 +0200

[Message part 1 (text/plain, inline)]

Sorry for not replying earlier, but I've been too busy with the RC1 
release of Debian Installer (and had to replace the hard disk in my 
laptop in the mean time too).

On Thursday 12 October 2006 12:05, Yuval Fledel wrote:
> > I have today uploaded a version of partman-partitioning that includes
> > a check for NTFS 3.1 partitions and refuses to resize in that case;
> > earlier NTFS partitions (NT, XP, 2000) should still be resizable.
>
> XP use NTFS 3.1 too. You've just blocked resizing of most users' NTFS
> partitions.

Thanks for that info. I have added some additional logic so that now only 
Vista is blocked and resizing XP partitions still works. I've even tested 
that while re-installing my laptop :-)

> > IMO #379628 should not be ignored for Etch and it would be nice if
> > someone else would try to either reproduce the bug or prove me wrong.
> > There is plenty of information in the BR for that. Without a working
> > ntfsresize, resizing NTFS 3.1 partitions is a no-op anyway.
>
> I've done some web searching and I have a wild guess about pcmcia.sys.
>
> After resizing, please boot into Vista's install disk and into the
> recovery console. From there, rename "system32\drivers\pcmcia.sys"
> (e.g. to "pcmcia.bak") and reboot. Does Vista now boots? What about
> Safe mode?

I'm sorry, but I currently don't have the time to do relatively wild 
attempts like that. Especially not as I've already verified that the 
md5sums of all files in the NTFS partition are unchanged after the resize 
operation (as documented in the history of this bug report).
Safe mode does not work either, it only shows roughly at what stage the 
boot hangs.

> Another solution I found on the net was for Win2003 and was replacing
> "ntldr" and "ntdetect.com" with the ones on the install disk. The best
> projection on a newly installed Vista would be to replace the files
> with files from Win2003 or XP. Does this solve the case?

That is bogus as Vista no longer uses ntldr, but instead uses bootmgr.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #168 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition (fwd)

Date: Sat, 28 Oct 2006 03:55:13 +0200

[Message part 1 (text/plain, inline)]

Please keep the Debian bug report CCed; therefore quoting your full mail.

Sorry for not replying earlier, but I've been too busy with the RC1 
release of Debian Installer (and had to replace the hard disk in my 
laptop in the mean time too).

On Thursday 12 October 2006 21:13, Szakacsits Szabolcs wrote:
> So far nobody else reported similar problem with Vista beta what you
> had, so below are some questions and suggestions.

OK, but has anybody actively tried to reproduce the issue? Or rather, have 
you had any positive reports that a resize operation for Windows Vista, 
roughly similar to what I have done, succeeded?
The absence of other reports does _not_ mean that there is no problem! I 
very much doubt all that many people are trying this yet.

> On Tue, 22 Aug 2006, Frans Pop wrote:
> > Looks like I made a mistake somehow while _creating_ the md5sum file.
> > It turns out the files are actually unchanged. I'm not sure what I've
> > done wrong, but the following leads me to conclude this was a false
> > lead: - after restoring the vmware image _before resize_, the files
> > that were
>
> Can you reproduce the bootability problem with the latest Vista Beta on
> 32-bit x86 (that's what most people use currently) if you shrink NTFS
> by 4 KB on a real hardware, real Vista installation (no vmware and
> other emulators involved at all)?

I already had reproduced it on 32-bit x86 as I used vmware. But I have now 
also reproduced it on real hardware.

While re-installing my laptop I _have_ tried again with the version I do 
have _after_ updating that using the MS update service to the current 
version. I got *exactly the same problems* when resizing to 10GB, so that 
now means I have reproduced the issue independently on three different 
platforms:
- my Pentium 4 laptop
- my EM64T desktop
- vmware

The resize test on my laptop was again without resizing the partition 
itself, but only the file system using ntfs-resize.

A resize of Windows XP (using Debian Installer) on my laptop went fine.

But no sorry, I cannot test with a current version of Vista. I bought the 
Beta2 version of Vista only to test the installer's support of it and am 
not all that interested in trying to get another version.

> Did you contact Microsoft with the bug report as I suggested? What did
> they answer? Perhaps they already fixed the Vista bootability bug in
> the newer betas?

No, I have no interest in persuing this with Microsoft. I'll gladly leave 
that to people more interested in actually using their products.

> Please note, if ntfsresize fails with Vista beta then it's highly
> possible that Partition Magic, Paragon, Acronis, BootitNG and all other
> NTFS resizers fail too. Microsoft did this mistake in the past which
> they had to correct later on and if they don't have the old devel team
> (which is very possible) then it's quite probably they will make the
> same mistake again unless somebody tells them before their final
> product release (that's why they release the buggy betas). So, even if
> you didn't notify Microsoft, others might did already, hence it would
> be worth retesting the problem with the latest Vista version. Could you
> do it please?

As I've said above, I personally have absolutely no interest in tracking 
this down further. I have done what I can, provided all information that 
I can be expected to provide with the software I have available. I think 
I have spent more time and effort on this than most people.
IMO it now really is up to the ntfs-resize community to track this issue 
down: send out calls to test this on your mailing lists, see if others 
can reproduce the problem or not. I'm a bit disappointed that that has 
not already happened since my last mail...
There must be others who _do_ have newer versions of Vista, and maybe even 
some who have both "my" version and newer ones and can compare them both.

What I did is well documented in the Debian bug report [1] and should be 
repeatable. Debian CD images are of course freely available :-)

I do very much appreciate your comments and suggestions which very much 
have helped narrow things down, but this is as far as I can go.

Please keep us informed if you do make progress on this issue. Even though 
I do not use Microsoft software myself anymore, I'd very much like to see 
Debian being able to support dual boot installations for systems running 
Vista.

Cheers,
FJP

[1] http://bugs.debian.org/379628

[Message part 2 (application/pgp-signature, inline)]

Message #173 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sat, 28 Oct 2006 19:25:18 +0300 (MET DST)

Hi,

Linux had no problem with Vista Beta NTFS support in the past but there is 
indication that this may have changed with the latest Vista Beta releases. 

I would like to ask people's help to confirm or refute this situation.

Please, anybody who has the possibility, follow the below instructions and
let us know if Vista can or can not boot:

  1. Install the __latest__ Vista Beta.

  2. Boot Linux or a LiveCD with ntfsresize included (most have and all
     ntfsresize versions must support the latest Vista Beta).

  3. Run the below command:

        ntfsresize -i <vista_partition>

     The "Current volume size:" field will show the NTFS size in bytes 
     and in MB, which is needed for the next step.

  4. Make NTFS size maximum 1 MB smaller:

        ntfsresize -s <new_size> <vista_partition>

     after which you should see a message like:

        "NTFS had been successfully resized on device <vista_partition>"

  5. Reboot into Vista. You must see the scheduled chkdsk running after
     which Vista should either continue booting fine (data partition) or
     automatically initiate a reboot of the computer (system partition).

Please also ask your friends, co-workers and communities to test this if 
they have the possibility. The community's help is very much needed now!

I'll post a summary of the feedbacks here and to all participants regularly 
until we have a definite conclusion.

Thank you in advance,

	Szaka

Message #178 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org

Subject: Re: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sat, 28 Oct 2006 18:52:22 +0200

[Message part 1 (text/plain, inline)]

On Saturday 28 October 2006 18:25, you wrote:
>   5. Reboot into Vista. You must see the scheduled chkdsk running after
>      which Vista should either continue booting fine (data partition)
> or automatically initiate a reboot of the computer (system partition).

Note that I have _never_ seen Vista run anything like a chkdsk in any of 
my tests. It would always just try to boot.

Windows XP does do the chkdsk correctly.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #183 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sat, 28 Oct 2006 22:09:12 +0300 (MET DST)

On Sat, 28 Oct 2006, Frans Pop wrote:
> On Saturday 28 October 2006 18:25, you wrote:
> >   5. Reboot into Vista. You must see the scheduled chkdsk running after
> >      which Vista should either continue booting fine (data partition)
> > or automatically initiate a reboot of the computer (system partition).
> 
> Note that I have _never_ seen Vista run anything like a chkdsk in any of 
> my tests. It would always just try to boot.

Technically it doesn't matter if chkdsk runs or not, boot must work in 
either case. In fact, there are people who remove the chkdsk scheduling 
from ntfsresize and have no problems.

It seems Vista boots from somewhere else, perhaps some short of boot cache, 
which failed to detect the underlaying filesystem change.

	Szaka

Message #188 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sat, 4 Nov 2006 22:26:29 +0300 (MET DST)

Hi,

Here is the promised summary. So far, it looks promising :)

	Success:	0
	Failure:	0

I've also asked help now on the ntfsresize faq page. 5000-7000 visitors a 
week. Let's see if they can help, I'll let you know.

	Szaka

On Sat, 28 Oct 2006, Szakacsits Szabolcs wrote:

> Linux had no problem with Vista Beta NTFS support in the past but there is 
> indication that this may have changed with the latest Vista Beta releases. 
> 
> I would like to ask people's help to confirm or refute this situation.
> 
> Please, anybody who has the possibility, follow the below instructions and
> let us know if Vista can or can not boot:
> 
>   1. Install the __latest__ Vista Beta.
> 
>   2. Boot Linux or a LiveCD with ntfsresize included (most have and all
>      ntfsresize versions must support the latest Vista Beta).
> 
>   3. Run the below command:
> 
>         ntfsresize -i <vista_partition>
> 
>      The "Current volume size:" field will show the NTFS size in bytes 
>      and in MB, which is needed for the next step.
> 
>   4. Make NTFS size maximum 1 MB smaller:
> 
>         ntfsresize -s <new_size> <vista_partition>
> 
>      after which you should see a message like:
> 
>         "NTFS had been successfully resized on device <vista_partition>"
> 
>   5. Reboot into Vista. You must see the scheduled chkdsk running after
>      which Vista should either continue booting fine (data partition) or
>      automatically initiate a reboot of the computer (system partition).
> 
> Please also ask your friends, co-workers and communities to test this if 
> they have the possibility. The community's help is very much needed now!
> 
> I'll post a summary of the feedbacks here and to all participants regularly 
> until we have a definite conclusion.
> 
> Thank you in advance,
> 
> 	Szaka
> 

Message #193 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sun, 05 Nov 2006 19:41:27 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

I have made a Vista partition 1MB smaller as per your instructions. I
can confirm that Vista does not boot anymore after this. Rather it hangs
on the black screen with the 'golden' progress bar with 'C 2006
Microsoft Corporation. All rights reserved.' written underneath.

I have tested this with Vista Pre-RC1, Build 5536 using ntfsresize 1.3.1
as it comes with GParted LiveCD 0.3.1.

Best regards,
Andree
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #198 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Mon, 6 Nov 2006 01:57:07 +0300 (MET DST)

Hi Andree,

On Sun, 5 Nov 2006, Andree Leidenfrost wrote:

> I have made a Vista partition 1MB smaller as per your instructions. I
> can confirm that Vista does not boot anymore after this. Rather it hangs
> on the black screen with the 'golden' progress bar with 'C 2006
> Microsoft Corporation. All rights reserved.' written underneath.

Thank you for testing! 

Btw, it would be nice to know if this is valid only for boot or also for 
data partitions?

So, it seems we should plan and implement denial of the resizing for 
Vista, asap. This is not so bad, because Vista started to include a 
non-destructive resizer.

Frans, how do you detect Vista? My idea is to check for the transactional 
directory. However this won't be enabled by default, so it may not exist
at all. 

> I have tested this with Vista Pre-RC1, Build 5536 using ntfsresize 1.3.1

I checked for the latest Vista beta, which is RC2 Build 5744 currently. So 
we still have hope that Microsoft has fixed this serious problem.

It also seems that only the members of the beta testing programme can 
submit bug reports.

	Szaka

Message #203 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Wed, 08 Nov 2006 00:29:36 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

Thanks a lot for your response!

On Mon, 2006-11-06 at 01:57 +0300, Szakacsits Szabolcs wrote:
> Hi Andree,
> 
> On Sun, 5 Nov 2006, Andree Leidenfrost wrote:
> 
> > I have made a Vista partition 1MB smaller as per your instructions. I
> > can confirm that Vista does not boot anymore after this. Rather it hangs
> > on the black screen with the 'golden' progress bar with 'C 2006
> > Microsoft Corporation. All rights reserved.' written underneath.
> 
> Thank you for testing! 
> 
> Btw, it would be nice to know if this is valid only for boot or also for 
> data partitions?

Ok, I've reinstalled and created a 10GB E: drive in Vista after that.
Surprisingly enough (at least to me), after reducing the size by 1MB
following your original instructions, Vista does not boot anymore
either. :-(

> So, it seems we should plan and implement denial of the resizing for 
> Vista, asap. This is not so bad, because Vista started to include a 
> non-destructive resizer.

As a Debian developer, i.e. looking at things from a distribution angle,
I am somewhat more concerned: Installing Linux on a PC should be as easy
as possible. To this date, ntfsresize has done an excellent job in
resizing an NTFS partition 'on the fly' as part of the Linux
installation process. It would be really sad to not have this
functionality anymore.

> Frans, how do you detect Vista? My idea is to check for the transactional 
> directory. However this won't be enabled by default, so it may not exist
> at all. 
> 
> > I have tested this with Vista Pre-RC1, Build 5536 using ntfsresize 1.3.1
> 
> I checked for the latest Vista beta, which is RC2 Build 5744 currently. So 
> we still have hope that Microsoft has fixed this serious problem.

I somewhat doubt that MS views this as a serious problem. I'd even
suspect they might have changed something on purpose to make it harder
for us to get this to work. (Then again I may be getting paranoid...)

> It also seems that only the members of the beta testing programme can 
> submit bug reports.
> 
> 	Szaka

Best regards,
Andree
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #208 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Wed, 8 Nov 2006 09:59:56 +0100

[Message part 1 (text/plain, inline)]

On Sunday 05 November 2006 23:57, Szakacsits Szabolcs wrote:
> So, it seems we should plan and implement denial of the resizing for
> Vista, asap. This is not so bad, because Vista started to include a
> non-destructive resizer.

Well, it is a pity that we will no longer be able to resize partitions 
from within the Debian installer. However, I guess that this will be a 
temporary denial until someone has figured out what would need to be 
changed to make the Vista boot working again.

> Frans, how do you detect Vista? My idea is to check for the
> transactional directory. However this won't be enabled by default, so
> it may not exist at all.

We currently check for the presence two files:
/bootmgr and /Boot/BCD

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #213 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Wed, 8 Nov 2006 11:27:52 +0100 (MET)

Hi,

On Wed, 8 Nov 2006, Andree Leidenfrost wrote:

> Thanks a lot for your response!

Thanks for yours too! :)
 
> Ok, I've reinstalled and created a 10GB E: drive in Vista after that.
> Surprisingly enough (at least to me), after reducing the size by 1MB
> following your original instructions, Vista does not boot anymore
> either. :-(

Interesting. I guess you've seen no error messages? 

We also shouldn't forget that this was an older beta release, so Vista bugs
are expected. It would be nice to reproduce it on the latest Vista too.
Unfortunately nobody could do it so far (that is no feedback).
 
> As a Debian developer, i.e. looking at things from a distribution angle,

As an all time Linux developer, I'm looking at things from all distributions
angle ;) I wrote ntfsresize for the purpose to be used in the Linux
installers. I never used Windows myself. I do understand your problem ;)

> I am somewhat more concerned: Installing Linux on a PC should be as easy
> as possible. To this date, ntfsresize has done an excellent job in
> resizing an NTFS partition 'on the fly' as part of the Linux
> installation process. 

The problem is that Parted still has problems with editing the partition
table. Corruptions still happen __sometimes__ in a way that Windows won't be
able to boot. Not even when it's reinstalled (the Windows install respects
the partition table, so it won't fix it). The Parted code is widely used in
QTParted (unmaintained for years), GParted and several other partitioners.
It keeps corrupting but isn't getting fixed. Very bad.

Another problem is GRUB. It also tends to make Windows unbootable
__sometimes__. GRUB seems to be also unmaintained for quite some time.

So this repartitioning approach doesn't seem to work reliable,
unfortunately.

An alternative could be if users would install Linux straight to NTFS.  
Thus the unreliable partitioning (and hopefully the bootloader) could be
eliminated completely. As an extra bonus, users would even have full
read-write access to their Linux data, without any additional setup.

Though this still needs some work on the NTFS side.

> It would be really sad to not have this functionality anymore.

I think this would be the correct way to proceed:

	1) reproduce the problem with the latest Vista Beta (afaik, RC2)

	2) submit a bug report to Microsoft and ask for answer and 
           workaround until they fix it

        3) if Microsoft ignores or refuses the problem then make it a
            legal cases against them as anti-competitive practices. 

	4) try to find a solution until 3) settles down.

Best regards,

	Szaka

Message #218 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Wed, 8 Nov 2006 12:41:49 +0100 (MET)

On Wed, 8 Nov 2006, Frans Pop wrote:

> On Sunday 05 November 2006 23:57, Szakacsits Szabolcs wrote:
> > So, it seems we should plan and implement denial of the resizing for
> > Vista, asap. This is not so bad, because Vista started to include a
> > non-destructive resizer.
> 
> Well, it is a pity that we will no longer be able to resize partitions 
> from within the Debian installer. However, I guess that this will be a 
> temporary denial until someone has figured out what would need to be 
> changed to make the Vista boot working again.

Yes. Microsoft could, well, should answer this, unless they fix or
already fixed their boot process.
 
> > Frans, how do you detect Vista? My idea is to check for the
> > transactional directory. However this won't be enabled by default, so
> > it may not exist at all.
> 
> We currently check for the presence two files:
> /bootmgr and /Boot/BCD

I'm afraid this is not ok for data partitions, which seemingly also have the
same problem. I suppose data partitions don't have the above two files, do
they?

Regards,
		Szaka

Message #223 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Thu, 9 Nov 2006 05:37:41 +0100

[Message part 1 (text/plain, inline)]

On Wednesday 08 November 2006 12:41, Szakacsits Szabolcs wrote:
> > We currently check for the presence two files:
> > /bootmgr and /Boot/BCD
>
> I'm afraid this is not ok for data partitions, which seemingly also
> have the same problem. I suppose data partitions don't have the above
> two files, do they?

No, but I'm surprised that data partitions should be affected too.
Of course they will also suffer from the starting sector problem we have 
in partman/parted (which we should be able to fix), but I would not have 
expected them to be corrupted by ntfsresize. Are you really sure of this?

[Message part 2 (application/pgp-signature, inline)]

Message #228 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: Andree Leidenfrost <andree@debian.org>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sourceforge.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 9 Nov 2006 09:03:01 +0100 (MET)

Hi,

Vista went gold. Unfortunately nobody could test the problem with the latest
Vista BETA, hence we don't know if the problem still exists or Microsoft
fixed it.

Thanks to all who did everything he could.

On Thu, 9 Nov 2006, Frans Pop wrote:

> No, but I'm surprised that data partitions should be affected too.
> Of course they will also suffer from the starting sector problem we have 
> in partman/parted (which we should be able to fix), but I would not have 
> expected them to be corrupted by ntfsresize. 

It doesn't look to be a filesystem corruption issue at all. The problem is
exactly that. Seemingly the Microsoft boot process completely ignores the
consistent NTFS and tries to boot via some other way but hangs.

Of course I don't expect Microsoft to fix ntfsresize, the problem is not
there. The problem is how they "boot" or "shutdown". They must be able to
detect that the underlaying file system was consistently changed and they
should adjust their boot process accordingly.

Or they should tell the world what state their OS is and developers can
detect, deny and let users know what they should exactly do to be able to
make modifications safely from non-Windows OSes.

I think Microsoft doesn't know they have a problem because nobody told them
yet. Bug reporting needs beta access but none of us is Vista beta tester.

> Are you really sure of this?

Andree confirmed that it's true for data partitions as well. You should have
got a copy too.

	Szaka

Message #233 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 9 Nov 2006 10:07:48 +0100

[Message part 1 (text/plain, inline)]

On Thursday 09 November 2006 09:03, Szakacsits Szabolcs wrote:
> > Are you really sure of this?
>
> Andree confirmed that it's true for data partitions as well. You should
> have got a copy too.

But that seems completely inconsistent with what you wrote in the rest of 
the mail: that it is a problem with 'how they "boot" or "shutdown"'.

[Message part 2 (application/pgp-signature, inline)]

Message #238 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sourceforge.net, Andree Leidenfrost <andree@debian.org>

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 9 Nov 2006 10:38:00 +0100 (MET)

[Frans: Could you please keep all interested parties CC'd? They don't get
your emails and I must add Andree and linux-ntfs-dev manually every time.
Thanks.]

On Thu, 9 Nov 2006, Frans Pop wrote:
> On Thursday 09 November 2006 09:03, Szakacsits Szabolcs wrote:
> >
> > Andree confirmed that it's true for data partitions as well. You should
> > have got a copy too.
> 
> But that seems completely inconsistent with what you wrote in the rest of 
> the mail: that it is a problem with 'how they "boot" or "shutdown"'.

Nobody seems to know what a data partition has to do with booting. Also
nobody confirmed yet that there is indeed a problem with Vista Gold.

Btw, what partition scheme does Vista use? Isn't it GPT? Couldn't the
problem be somehow related to that? 

Ntfsresize completely ignores the storage type by design. It can be file,
MBR, GPT, LDM, whatever. It works 100% independently of them, so the storage
type related work can be and often __must__ be done independently.

There is this MS document (Vista is based on W2K3):

  http://technet2.microsoft.com/WindowsServer/en/library/bdeda920-1f08-4683-9ffb-7b4b50df0b5a1033.mspx?mfr=true

If somebody has the time (sorry, I don't) then perhaps he could take a look.
Maybe there is something useful info related to this problem.

	Szaka

Message #243 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Frans Pop <elendil@planet.nl>, 379835@bugs.debian.org

Cc: debian-release@lists.debian.org, 380226@bugs.debian.org, 379628@bugs.debian.org

Subject: Re: Bug#379835: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important

Date: Fri, 10 Nov 2006 19:21:00 -0800

Hi Frans,

On Thu, Oct 12, 2006 at 07:59:34AM +0200, Frans Pop wrote:

> There are currently three RC bugs open related to the resizing of NTFS 3.1 
> partitions as created by Windows Vista.

> - #379628: ntfsresize - upstream bug, but disputed; I can reproduce it
>            reliably though; needs confirmation by someone else
> - #380226: libparted - clear issue, recently further traced during BSP in
>            Utrecht; needs attention from Debian maintainer and upstream
> - #379835: partman - no bug in partman itself, but the result of the two
>            listed above (blocked by both)

> I have today uploaded a version of partman-partitioning that includes a 
> check for NTFS 3.1 partitions and refuses to resize in that case; earlier 
> NTFS partitions (NT, XP, 2000) should still be resizable.
> As partman is now "safe" I am downgrading #379835 to important.

> For #380226 I recommend tagging it 'etch-ignore'. 
> The reason I think it's safe to do that is that it may only manifest 
> itself in the installer. I'm unsure where else and how libparted is used 
> though.
> I have tried resizing an NTFS 3.1 partition using parted, and that 
> correctly left the starting partition unchanged, so parted is unaffected.

> IMO #379628 should not be ignored for Etch and it would be nice if someone 
> else would try to either reproduce the bug or prove me wrong. There is 
> plenty of information in the BR for that. Without a working ntfsresize, 
> resizing NTFS 3.1 partitions is a no-op anyway.

I'm having a hard time distilling the information in these bug reports into
a summary of what each bug is actually about or what the current status is.
(Having two bugs with the same bug title doesn't help matters any. :/)
Isn't it the case that there is a workaround in place now in the Debian
packages that prevents resizing of NTFS filesystems if they're detected as
belong to a recent version of Vista?  Is this workaround implemented
somewhere *other* than the linux-ntfs package?

If linux-ntfs now correctly avoids resizing filesystems that it can't ensure
are usable afterwards, I would argue that 379628 should be downgraded
(though of course it would be great to have it fixed in time for etch!).
But I guess you've put this workaround in partman-partitioning, not in the
package that contains the actual bug?  If linux-ntfs does not yet have such
a workaround in place, let me know and I'll try to work on providing one.

Your rationale for ignoring 380226 also makes no sense to me; if this bug
manifests in the installer, isn't that still a data loss bug that we need to
fix before release?  There are also two other packages in testing, gparted
and mindi, which use libparted, so if there's a dataloss-causing bug in
libparted I don't see that it's ignorable even if we did accept an argument
that data loss in the installer is ok (which I don't).  But again, I don't
understand how libparted has a bug separate from the linux-ntfs one.

Can someone who understands what's going on with these bugs please fix up
the bug titles so that they're an accurate summary, to help the rest of us
figure out which bits of information in the bug log are relevant to the
current bugs?

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #248 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)

Date: Sat, 11 Nov 2006 19:42:39 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

On Wed, 2006-11-08 at 11:27 +0100, Szakacsits Szabolcs wrote: 
> Hi,
> 
> On Wed, 8 Nov 2006, Andree Leidenfrost wrote:
> 
> > Thanks a lot for your response!
> 
> Thanks for yours too! :)

:-)

> > Ok, I've reinstalled and created a 10GB E: drive in Vista after that.
> > Surprisingly enough (at least to me), after reducing the size by 1MB
> > following your original instructions, Vista does not boot anymore
> > either. :-(
> 
> Interesting. I guess you've seen no error messages? 

I had another look and used F6->F8->Safe Mode with Command Prompt. In
the attached screenshot you can see that it stops after it loaded
crcdisk.sys. 

Google says other people experience the same.

Unfortunately the Recovery Console seems to be gone. When I try to boot
the Vista install DVD it hangs as well. Any idea how I could possibly
run chkdsk?

> We also shouldn't forget that this was an older beta release, so Vista bugs
> are expected. It would be nice to reproduce it on the latest Vista too.
> Unfortunately nobody could do it so far (that is no feedback).
>  
> > As a Debian developer, i.e. looking at things from a distribution angle,
> 
> As an all time Linux developer, I'm looking at things from all distributions
> angle ;) I wrote ntfsresize for the purpose to be used in the Linux
> installers. I never used Windows myself. I do understand your problem ;)

Fair enough. :-)

> > I am somewhat more concerned: Installing Linux on a PC should be as easy
> > as possible. To this date, ntfsresize has done an excellent job in
> > resizing an NTFS partition 'on the fly' as part of the Linux
> > installation process. 
> 
> The problem is that Parted still has problems with editing the partition
> table. Corruptions still happen __sometimes__ in a way that Windows won't be
> able to boot. Not even when it's reinstalled (the Windows install respects
> the partition table, so it won't fix it). The Parted code is widely used in
> QTParted (unmaintained for years), GParted and several other partitioners.
> It keeps corrupting but isn't getting fixed. Very bad.
> 
> Another problem is GRUB. It also tends to make Windows unbootable
> __sometimes__. GRUB seems to be also unmaintained for quite some time.
> 
> So this repartitioning approach doesn't seem to work reliable,
> unfortunately.
> An alternative could be if users would install Linux straight to NTFS.  
> Thus the unreliable partitioning (and hopefully the bootloader) could be
> eliminated completely. As an extra bonus, users would even have full
> read-write access to their Linux data, without any additional setup.
> Though this still needs some work on the NTFS side.
> 
> > It would be really sad to not have this functionality anymore.
> 
> I think this would be the correct way to proceed:
> 
> 	1) reproduce the problem with the latest Vista Beta (afaik, RC2)
> 
> 	2) submit a bug report to Microsoft and ask for answer and 
>            workaround until they fix it
> 
>         3) if Microsoft ignores or refuses the problem then make it a
>             legal cases against them as anti-competitive practices. 
> 
> 	4) try to find a solution until 3) settles down.
> 
> Best regards,
> 
> 	Szaka

Just in case anybody reading this would be interested: If anyone has a
Vista installation that I could destroy in Sydney in order to confirm
the issue on the final version, drop me a message!

Cheers,
Andree
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[Vista_start_failure.jpg (image/jpeg, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #253 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sourceforge.net, 379628@bugs.debian.org, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 11 Nov 2006 13:54:16 +0100

Szakacsits Szabolcs wrote:
> On Thu, 9 Nov 2006, Frans Pop wrote:
>> On Thursday 09 November 2006 09:03, Szakacsits Szabolcs wrote:
>>> Andree confirmed that it's true for data partitions as well. You should
>>> have got a copy too.
>> But that seems completely inconsistent with what you wrote in the rest of 
>> the mail: that it is a problem with 'how they "boot" or "shutdown"'.
> 
> Nobody seems to know what a data partition has to do with booting. Also
> nobody confirmed yet that there is indeed a problem with Vista Gold.

Perhaps try replacing ntdetect.com and ntldr with the versions that came
with an earlier Vista beta? For reference see:
http://groups.google.com/group/microsoft.public.windows.server.setup/browse_frm/thread/7944a6046ab2f6ac/24312e94802d196a?tvc=1

Another interesting thing would be to compare NTFS data partitions from
before a Vista install and after install. Maybe we can find a difference
that allows detecting that Vista has accessed such a partition.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Message #258 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Sat, 11 Nov 2006 21:43:40 +0200 (MET DST)

Hi,

On Sat, 11 Nov 2006, Andree Leidenfrost wrote:

> I had another look and used F6->F8->Safe Mode with Command Prompt. In
> the attached screenshot you can see that it stops after it loaded
> crcdisk.sys. 
> 
> Google says other people experience the same.

Thanks, I've checked some Google posts.

There are quite many different scenarios when boot hangs at crcdisk.sys. 
This is how the drivers should be loaded usually around crcdisk.sys:

  Loaded driver \Windows\System32\Drivers\spldr.sys
  Loaded driver \Windows\System32\Drivers\Mup.sys
  Loaded driver \Windows\system32\drivers\disk.sys
  Loaded driver \Windows\system32\drivers\CLASSPNP.SYS
  Loaded driver \Windows\system32\drivers\crcdisk.sys
  Loaded driver \SystemRoot\system32\drivers\Wdf01000.sys
  Loaded driver \SystemRoot\system32\drivers\intelppm.sys
  Loaded driver \SystemRoot\system32\drivers\uagp35.sys

One can notice the path change right after loading crcdisk.sys. What is 
SystemRoot? There isn't such directory on NTFS. Microsoft says "Set the 
current directory to the systemroot folder of the Windows installation you 
are logged on to."

There is also one important thing to know. The windows boot process is an 
old legacy. It's not a modern one, for example, what Linux has. In the 
early boot phrase a mini ntfs driver loads the real drivers and at some 
point the boot process starts to use them.

Apparently this point is right after crcdisk.sys, so that's why so many 
people have problem there. Millions of things can go wrong during the 
driver "switch" and they indeed do go wrong but the fault will always point 
to crcdisk.sys.

All posts I've seen was old, or if it wasn't then it used old Vista Beta.

GParted was used with Vista RC1 in the below article. Same hang but chkdsk 
fixed the boot problem: 
http://opensource.apress.com/article/163/taking-a-look-at-vista-part-iii

If one could send me the two ntfs images, before and after running chkdsk, 
then I could add the needed support, suppose the problem is indeed due NTFS 
changes. Instructions how to create the images are here:

  http://wiki.linux-ntfs.org/doku.php?id=ntfsclone#store_only_ntfs_metadata

But the most important thing would be still to reproduce the problem with 
the latest Vista, so we could confirm that we indeed have a problem. Which 
means that we still haven't received any information how ntfsresize works 
with the latest Vista.

> Just in case anybody reading this would be interested: If anyone has a
> Vista installation that I could destroy in Sydney in order to confirm
> the issue on the final version, drop me a message!

Btw, it would be also nice to test ntfsclone, if one is interested:

	1) ntfsclone --overwrite vista.img vista_partition

	2) zero the entire vista partition (not the disk!):

		dd if=/dev/zero of=vista_partition

	3) ntfsclone --overwrite vista_partition vista.img

	4) vista should boot fine

Cheers,
	Szaka

Message #263 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Cc: linux-ntfs-dev@lists.sourceforge.net, 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 11 Nov 2006 22:39:53 +0200 (MET DST)

On Sat, 11 Nov 2006, Carl-Daniel Hailfinger wrote:
> 
> Perhaps try replacing ntdetect.com and ntldr with the versions that came
> with an earlier Vista beta? For reference see:
> http://groups.google.com/group/microsoft.public.windows.server.setup/browse_frm/thread/7944a6046ab2f6ac/24312e94802d196a?tvc=1

This is an XP/W2K3 problem. Vista doesn't use ntldr.
 
> Another interesting thing would be to compare NTFS data partitions from
> before a Vista install and after install. Maybe we can find a difference
> that allows detecting that Vista has accessed such a partition.

The most important is to verify that there is still a problem to be solved. 

If yes, then we'll add Vista NTFS detection and resizing refusal which 
should be taken into use asap. Afterwards we'll have time to investigate if 
the situation is solvable technically or legally.

	Szaka

Message #268 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Sun, 12 Nov 2006 22:56:27 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

On Sat, 2006-11-11 at 21:43 +0200, Szakacsits Szabolcs wrote:
> Hi,
> 
> On Sat, 11 Nov 2006, Andree Leidenfrost wrote:
> 
> > I had another look and used F6->F8->Safe Mode with Command Prompt. In
> > the attached screenshot you can see that it stops after it loaded
> > crcdisk.sys. 
> > 
> > Google says other people experience the same.
> 
> Thanks, I've checked some Google posts.
> 
> There are quite many different scenarios when boot hangs at crcdisk.sys. 
> This is how the drivers should be loaded usually around crcdisk.sys:
> 
>   Loaded driver \Windows\System32\Drivers\spldr.sys
>   Loaded driver \Windows\System32\Drivers\Mup.sys
>   Loaded driver \Windows\system32\drivers\disk.sys
>   Loaded driver \Windows\system32\drivers\CLASSPNP.SYS
>   Loaded driver \Windows\system32\drivers\crcdisk.sys
>   Loaded driver \SystemRoot\system32\drivers\Wdf01000.sys
>   Loaded driver \SystemRoot\system32\drivers\intelppm.sys
>   Loaded driver \SystemRoot\system32\drivers\uagp35.sys
> 
> One can notice the path change right after loading crcdisk.sys. What is 
> SystemRoot? There isn't such directory on NTFS. Microsoft says "Set the 
> current directory to the systemroot folder of the Windows installation you 
> are logged on to."
> 
> There is also one important thing to know. The windows boot process is an 
> old legacy. It's not a modern one, for example, what Linux has. In the 
> early boot phrase a mini ntfs driver loads the real drivers and at some 
> point the boot process starts to use them.
> 
> Apparently this point is right after crcdisk.sys, so that's why so many 
> people have problem there. Millions of things can go wrong during the 
> driver "switch" and they indeed do go wrong but the fault will always point 
> to crcdisk.sys.
> 
> All posts I've seen was old, or if it wasn't then it used old Vista Beta.
> 
> GParted was used with Vista RC1 in the below article. Same hang but chkdsk 
> fixed the boot problem: 
> http://opensource.apress.com/article/163/taking-a-look-at-vista-part-iii
> 
> If one could send me the two ntfs images, before and after running chkdsk,

The problem for me is how to run chkdsk after the resize. If you can
tell me how I'll do it.

> then I could add the needed support, suppose the problem is indeed due NTFS 
> changes. Instructions how to create the images are here:
> 
>   http://wiki.linux-ntfs.org/doku.php?id=ntfsclone#store_only_ntfs_metadata

How about I do this before and after the resize?

> But the most important thing would be still to reproduce the problem with 
> the latest Vista, so we could confirm that we indeed have a problem. Which 
> means that we still haven't received any information how ntfsresize works 
> with the latest Vista.
> 
> > Just in case anybody reading this would be interested: If anyone has a
> > Vista installation that I could destroy in Sydney in order to confirm
> > the issue on the final version, drop me a message!
> 
> Btw, it would be also nice to test ntfsclone, if one is interested:
> 
> 	1) ntfsclone --overwrite vista.img vista_partition
> 
> 	2) zero the entire vista partition (not the disk!):
> 
> 		dd if=/dev/zero of=vista_partition
> 
> 	3) ntfsclone --overwrite vista_partition vista.img
> 
> 	4) vista should boot fine

Yep, tried that and it works fine. :-)

> Cheers,
> 	Szaka
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #273 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Sun, 12 Nov 2006 14:14:09 +0200 (MET DST)

On Sun, 12 Nov 2006, Andree Leidenfrost wrote:
> On Sat, 2006-11-11 at 21:43 +0200, Szakacsits Szabolcs wrote:
> > GParted was used with Vista RC1 in the below article. Same hang but chkdsk 
> > fixed the boot problem: 
> > http://opensource.apress.com/article/163/taking-a-look-at-vista-part-iii
> > 
> > If one could send me the two ntfs images, before and after running chkdsk,
> 
> The problem for me is how to run chkdsk after the resize. If you can tell 
> me how I'll do it.

I think, your only chance is Google.
 
> How about I do this before and after the resize?

Thanks but that would be useless. I exactly know what it does with Vista 
volumes. The only interesting thing is what and how chkdsk modifies 
metadata to make Vista boot again.

But I would still focus only on the latest Vista. 
 
> > Btw, it would be also nice to test ntfsclone, if one is interested:
>
> Yep, tried that and it works fine. :-)

Thanks :) So the ntfsresize test isn't destructive if one makes an 
ntfsclone backup previously.

	Szaka

Message #278 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Sun, 12 Nov 2006 15:23:10 +0200 (MET DST)

Hi,

On Sun, 12 Nov 2006, Szakacsits Szabolcs wrote:
> On Sun, 12 Nov 2006, Andree Leidenfrost wrote:
> > 
> > The problem for me is how to run chkdsk after the resize. If you can tell 
> > me how I'll do it.
> 
> I think, your only chance is Google.
...  
> But I would still focus only on the latest Vista. 

I explain.

You have pre-RC1, he had RC1. Chkdsk may not worked in pre-RC1, only in 
RC1. So, you are maybe looking for a solution which is supposed to work 
only in RC1.

The same is true for not being able to boot. This may be solved only in RC2
but not earlier.

Currently the situation is like if we're trying to solve a problem in 
development kernel version 2.5.12 which nobody else could reproduce with 
the latest, stable kernels version 2.6.18.2.

Btw, still nobody could provide info related to the latast Vista. I guess 
it's time to disable Vista support due to lack of interest and to be on the 
safe side. We can continue investigating this problem when Vista will be 
more widely available.

	Szaka

Message #283 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379835@bugs.debian.org, debian-release@lists.debian.org, 380226@bugs.debian.org, 379628@bugs.debian.org

Subject: Re: Bug#379835: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important

Date: Wed, 22 Nov 2006 23:16:09 +0100

[Message part 1 (text/plain, inline)]

On Saturday 11 November 2006 04:21, Steve Langasek wrote:
> I'm having a hard time distilling the information in these bug reports
> into a summary of what each bug is actually about or what the current
> status is.

I don't find that at all surprising as it cost me a lot of hours to get 
get the info collected, the issues identified and, in the case of 
ntfsprogs, upstream convinced [1].

> Isn't it the case that there is a workaround in place
> now in the Debian packages that prevents resizing of NTFS filesystems
> if they're detected as belong to a recent version of Vista?

s/a recent version of//

> Is this workaround implemented somewhere *other* than the linux-ntfs
> package? 

Yes, it is implemented in partman, not ntfs-resize. Partman now blocks 
resizing of any partition containing the Vista OS (or rather: the files 
that are used to boot Vista). It does not block resizing data partitions.

The upstream maintainer of ntfsprogs only recently was convinced that the 
issue is real. He has said he wants to block resizing Vista partitions, 
but I don't know if that has been implemented yet. It is certainly not 
yet in Debian.
There is some uncertainty if the ntfsresize issue only affects Vista OS 
partitions or if it also extends to (Vista) data partitions.

Note that I have also seen two recent reports about issues with corruption 
of XP NTFS partitions (#394963), though that seems unrelated to resizing.

[this quote moved up a bit]
> But again, I don't understand how libparted has a bug separate from the
> linux-ntfs one. 

[quote from message Saturday 11 November 2006 04:38]
> I'm not sure there's any reason this bug would be specific to NTFS
> partitions, though, is there? 

libparted causes the starting sector of the partition to change, thus 
making the physical partition invalid. This bug is indeed not even 
strictly related to Vista partitions, but other partitions seem to get 
created aligned on cylinder boundaries by default (or we'd have seen a 
lot more bug reports).

ntfsresize somehow causes an corruption of internal consistency (probably 
some meta-data about the partition is saved somewhere and is not updated 
after the resize) that is expected by the Vista bootloader.

> Your rationale for ignoring 380226 also makes no sense to me; if this
> bug manifests in the installer, isn't that still a data loss bug that
> we need to fix before release?  There are also two other packages in
> testing, gparted and mindi, which use libparted, so if there's a
> dataloss-causing bug in libparted I don't see that it's ignorable even
> if we did accept an argument that data loss in the installer is ok
> (which I don't).

There are a few reasons why I thought we could tag the libparted issue 
etch-ignore:
1) it is not a regression from Sarge
2) there has been precious little attention to the issue from the
   maintainers of parted even though the BR was already 3 months old;
   I talked to Otavio today though and he promised to start on it
3) the chance that people will resize a partition not aligned on a
   cylinder boundary outside d-i seems pretty slim
4) it is not dataloss is the strict sense: you can recover by changing
   the staring sector back to its old value (the trick is how to find
   out what the old value was...)

Resizing a partition that is not on a cylinder boundary is scary anyway: 
fdisk will also do the wrong thing unless you remember to change the 
units it uses from cylinders to sectors (using its 'u' command).

I did check parted itself and that does the right thing as it asks for the 
starting sector (IIRC). I have no idea about gparted and mindi.

If you feel the libparted bug should be fixed before the release, that is 
perfectly fine by me. However, it really is an upstream issue and there 
probably is a very good reason why that alignment check was originally 
added. I would not want to just apply Bas' patch and hope for the best.

> Can someone who understands what's going on with these bugs please fix
> up the bug titles so that they're an accurate summary, to help the rest
> of us figure out which bits of information in the bug log are relevant
> to the current bugs?

IMHO the bug reports are pretty clear. They all have the same origin: /me 
having problems booting vista after resizing its NTFS partition, but have 
diverged at some point to deal with the separate issues.

There is no actual bug in partman, but the two other bugs makes a 
workaround there necessary until the other two issues are fixed, hence 
the blocks.
It could be argued that partman should also check if a partition in an 
msdos partition table is aligned on a cylinder boundary before allowing 
to resize, but I feel the risk of that happening for non-Vista partitions 
is small enough to ignore it (people should always backup their data 
before resizing anyway, right?).
If someone would supply a patch for that I'd apply it though.

The BR against ntfsprogs has grown huge, mostly because it took a lot of 
effort to convince the upstream maintainer that there really was an 
issue.

I am keeping track of all three BRs, so feel free to ask me for additional 
info if you need it.

Cheers,
FJP

[1] I must say though that without the help from the ntfsprogs upstream I 
would never have gotten the issues identified at all.

[Message part 2 (application/pgp-signature, inline)]

Message #288 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 23 Nov 2006 00:12:40 +0100

[Message part 1 (text/plain, inline)]

> If one could send me the two ntfs images, before and after running
> chkdsk, then I could add the needed support, suppose the problem is
> indeed due NTFS changes.

I've tried this in vmware. Apparently you should be able to use the Vista 
installer's "Recovery Environment" [1] to run chkdsk.
Unfortunately it seems that the Vista installer dislikes what ntfsresize 
has done so much that that also fails to boot! I am completely amazed 
that an installer can fail to boot because of changes in a partition on 
the harddisk, but M$ seems to have managed it.

I can still boot the installer (and access the recovery options) if I use 
a snapshot for a "working" Vista, so it must be somehow related to the 
resize.

I'll give it a try on "real" hardware as well, but unsure when I'll be 
able to do that.

Cheers,
FJP

[1] http://blogs.msdn.com/winre/archive/2006/09/18/760295.aspx

[Message part 2 (application/pgp-signature, inline)]

Message #293 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 23 Nov 2006 01:27:39 +0200 (MET DST)

On Thu, 23 Nov 2006, Frans Pop wrote:

> I've tried this in vmware. Apparently you should be able to use the Vista 
> installer's "Recovery Environment" [1] to run chkdsk.
> Unfortunately it seems that the Vista installer dislikes what ntfsresize 
> has done so much that that also fails to boot! 

It's possible that it checks the boot sector for changes, e.g. against 
viruses, rootkits, etc. A few vital NTFS information __must__ be changed 
there when the volume is resized. Perhaps these modifications are 
interpreted as security risk so it silently refuses to boot.

Many people use ntfs-3g with Vista fine. And the code is the same, so the 
reason must be something trivial, boot/security related issue.

> I am completely amazed that an installer can fail to boot because of 
> changes in a partition on the harddisk, but M$ seems to have managed it.

Could you manage to get a final Vista or is this old the pre-Beta1? 
I still didn't get any feedback.

Thanks,
	Szaka

Message #298 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 23 Nov 2006 00:47:26 +0100

[Message part 1 (text/plain, inline)]

On Thursday 23 November 2006 00:27, Szaka wrote:
> It's possible that it checks the boot sector for changes, e.g. against
> viruses, rootkits, etc.

I still don't see why it should affect booting the _installer_. Is 
reinstallation not the final (and in the case of Windows often the only) 
option to get back to a working system after a partition was "damaged"?
Now you don't even have that option...

> Could you manage to get a final Vista or is this old the pre-Beta1?

It is the Vista Beta2 installation DVD I've been using all along.

[Message part 2 (application/pgp-signature, inline)]

Message #303 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)

Date: Thu, 23 Nov 2006 01:54:15 +0200 (MET DST)

On Thu, 23 Nov 2006, Frans Pop wrote:
> On Thursday 23 November 2006 00:27, Szaka wrote:
> > It's possible that it checks the boot sector for changes, e.g. against
> > viruses, rootkits, etc.
> 
> I still don't see why it should affect booting the _installer_. 

I think this is a beta2 bug which was fixed quite probably already before 
the final vista release. Beta releases work the way you describe. They make 
no sense so they get fixed.

I suppose you still only used ntfsresize, and no partitioning was involved, 
which could indeed cause bootability problems.

> Is reinstallation not the final (and in the case of Windows often the 
> only) option to get back to a working system after a partition was 
> "damaged"? Now you don't even have that option...

Let's not speculate until we know what the final Vista does.
 
Cheers,
	Szaka

Message #308 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, elendil@planet.nl

Subject: Problem persists with Vista Final

Date: Fri, 24 Nov 2006 07:14:21 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

I can confirm that unfortunately the problem persists in the final
version of Vista. :-(

Regards,
Andree

PS: I was given the opportunity to test this but have not purchased a
copy of Vista and don't intend to. I can possibly do some more testing
but it would be easier (and quicker) if someone else stepped up that
owns a copy him- or herself. This could of course also be a company.
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #313 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Andree Leidenfrost <andree@debian.org>

Cc: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, elendil@planet.nl

Subject: Re: [Linux-NTFS-Dev] Problem persists with Vista Final

Date: Thu, 23 Nov 2006 21:26:36 +0000 (GMT)

On Fri, 24 Nov 2006, Andree Leidenfrost wrote:
> I can confirm that unfortunately the problem persists in the final
> version of Vista. :-(

A little theory (which may be crap):

Vista makes use of TPM chips as present in latest PC hardware.  From what 
I read once about how they are used, these make the entirety of the boot 
process cryptograpically tamperproof (or at least they are meant to do 
that, I have no idea how "tamperproof" they really are) so that if at 
_any_ point during boot anything has changed at all the OS will not boot 
at all.  This sounds like exactly that.  Presumably the boot sector (if 
nothing else) fails the TPM check as its crypto hash will have changed.

If this little theory is correct (and I am not claiming that it is, I am 
just saying that it _could_ be correct) then ntfsresize is basically 
screwed and can never work on PCs with enabled TPM chips and Vista.  And 
what's worse I doubt there is any way for ntfsresize to know whether the 
disk belongs to a machine with a TPM chip or not and even less whether 
it is turned on or off...  )-:

I can only hope that my little theory is just a pile of crap!

At least it seems like one can turn of the TPM chip in Vista (as long as 
one controls the computer but I assume ntfsresize users have admin 
passwords to their computers anyway) so if I am right and this is the 
problem ntfsresize could warn users to disable the TPM chip _before_ 
running ntfsresize...

It would be interesting to turn off the TPM chip on a modern PC and then 
try ntfsresize and if it works turn it on and try again.  If it then 
breaks I am right and if it breaks with the TPM chip turned off then my 
theory is just that, a theory.  (-;

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #318 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 25 Nov 2006 00:59:39 +0100

[Message part 1 (text/plain, inline)]

On Saturday 11 November 2006 20:43, Szakacsits Szabolcs wrote:
> If one could send me the two ntfs images, before and after running
> chkdsk, then I could add the needed support, suppose the problem is
> indeed due NTFS changes.

Think I've got it.
I've installed Vista Beta2 on my AMD64 box, resized the partition from 40 
to 35 GB (ntfsresize only) => Vista fails to boot.
Try repair with Vista installer => installer fails to boot.
Use Windows 2000 (!) installation CD => chkdsk finds and repairs errors.
Vista installer now boots, run its repair function => Vista boots again.

I have put the NTFS images and some other files at:
http://people.debian.org/~fjp/vista/

Here is the detailed procedure I've followed. This also explains the files 
available from the URL above.

- Install Vista in 40GB partition
- From Linux:
  - run ntfsclone to generate 'pre-resize' image
  - run md5sum on all files in Vista partition
  - save files in Vista /Boot directory
- Resize NTFS partition to 35GB (using ntfsresize only)
- From Linux:
  - run ntfsclone to generate 'post-resize' image (needed --force)
  - running 'md5sum -c' shows no files changed
- Run Windows 2000 chkdsk
- Run Vista installer repair utility
- From Linux:
  - run ntfsclone to generate 'post-repair' image
  - running 'md5sum -c' shows changes:
    http://people.debian.org/~fjp/vista/post-repair/md5sum.log
    - 1 file deleted: /pagefile.sys
    - 10 files changed
  - save files in Vista /Boot directory again
  - save changed files in Vista /Windows/System32/config directory
- Boot Vista (boot was a bit slow, but successful)

I hope the info available now will be sufficient to track down the 
problem. If not, I could repeat the procedure and also generate an image 
after running the Windows 2000 chkdsk. I could also make a copy of the 
the other files that were changed during the repair process.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #323 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 25 Nov 2006 02:17:56 +0200 (MET DST)

Hi,

Thanks for your help and the images.

On Sat, 25 Nov 2006, Frans Pop wrote:

> I hope the info available now will be sufficient to track down the 
> problem. If not, I could repeat the procedure and also generate an image 
> after running the Windows 2000 chkdsk. 

Please. That could be very useful. And please also send what chkdsk logs.
It can be viewed according to

	http://en.wikipedia.org/wiki/CHKDSK#Viewing_results

Andree, thanks to you too for the report that Vista Gold still has the 
problem.

Cheers,
	Szaka

Message #328 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 25 Nov 2006 04:03:25 +0200 (MET DST)

Hi,

Could you please try this after running ntfsresize and before booting 
Vista:

  dd if=<PARTITION> bs=512 count=1 | dd of=<PARTITION> seek=<LAST_SECTOR>

where <LAST_SECTOR> is the last sector on <PARTITION>. It can be calculated 
by running 

  sfdisk -d <DISK> | grep <PARTITION> 

and then by subtracting 1 from the value of 'size'.

Please let me know if this makes Vista boot or not. 

Thanks,
	Szaka

Message #333 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 25 Nov 2006 17:58:54 +0100

[Message part 1 (text/plain, inline)]

On Saturday 25 November 2006 01:17, Szakacsits Szabolcs wrote:
> On Sat, 25 Nov 2006, Frans Pop wrote:
> > I hope the info available now will be sufficient to track down the
> > problem. If not, I could repeat the procedure and also generate an
> > image after running the Windows 2000 chkdsk.
>
> Please. That could be very useful.

Information on http://people.debian.org/~fjp/vista/ updated (previous run 
saved as vista.old) and info for after the chkdsk using Win2k added.

I've stopped after the Win2k chkdsk as that turned out to be sufficient to 
make Vista boot again, so running the Vista repair is unnecessary!
The md5sum check after running chkdsk showed only /pagefile.sys deleted.

This means that the new images hopefully show the minimal changes needed 
to fix the problem.

> And please also send what chkdsk logs.

C:\Windows>chkdsk
Volume created 11/25/06  03:01p
The volume Serial Number is 9691-8fb7
CHKDSK is checking the volume...
CHKDSK is performing additional checking or recovery...
CHKDSK is performing additional checking or recovery...
CHKDSK is performing additional checking or recovery...
CHKDSK found one or more errors on the volume.
 34179680 kilobytes total disk space.
 27777968 kilobytes are available.

     4096 units in each allocation unit.
  8544920 total allocation units on disk.
  6944492 allocation units available on disk.


On Saturday 25 November 2006 03:03, Szakacsits Szabolcs wrote:
> Could you please try this after running ntfsresize and before booting
> Vista:
>  dd if=<PARTITION> bs=512 count=1 | dd of=<PARTITION> seek=<LAST_SECTOR>

This did not work (Vista still unbootable).

[Message part 2 (application/pgp-signature, inline)]

Message #338 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 26 Nov 2006 03:13:09 +0200 (MET DST)

On Sat, 25 Nov 2006, Frans Pop wrote:
> 
> I've stopped after the Win2k chkdsk as that turned out to be sufficient to 
> make Vista boot again, so running the Vista repair is unnecessary!
> The md5sum check after running chkdsk showed only /pagefile.sys deleted.

Yes, there isn't really anything special except deleting /pagefile.sys
which is __highly__ unusual.

Quite probably this means that the pagefile.sys format has changed and 
Vista stores information there for faster boots. It boots like Linux 
softsuspend.

Could you please also test that whether Vista boots if you remove 
/pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in 
Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage 
Or use a LiveCD which has both. The above page lists several of them.

Thanks,
	Szaka

Message #343 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 26 Nov 2006 17:41:24 +0100

[Message part 1 (text/plain, inline)]

On Sunday 26 November 2006 02:13, you wrote:
> Could you please also test that whether Vista boots if you remove
> /pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in
> Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage
> Or use a LiveCD which has both. The above page lists several of them.

Used ntfs-3g for this, but Vista still refuses to boot.

But.... progress!

I've managed to boot Vista using the following procedure (which I found by 
accident when ntfs-3g complained about not being able to mount the NTFS 
partition):
- resize Vista partition
- reboot into Vista (which fails at the point we all know so well by now)
  Vista marks the boot as unsuccessful (next boot it will offer the safe
  boot option, but still not run chkdsk by itself)
- reboot into linux
- (try mounting the partition using ntfs-3g which fails)
- run ntfsfix
- reboot into Vista, this will at last run chkdsk!
- Vista reboots automatically after the chkdsk and this time successfully!

So, what does ntfsfix do on a ntfs volume marked "dirty" by Vista that 
ntfsresize does not?
# ntfsfix /dev/sda1
Mounting volume... FAILED
Attempting to correct errors...
Processing $FMT amd $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.

Attached 3 screenshots that show Vista's chkdsk output.

Cheers,
FJP

[vista_chkdsk_1.png (image/png, attachment)]

[vista_chkdsk_2.png (image/png, attachment)]

[vista_chkdsk_3.png (image/png, attachment)]

[Message part 5 (application/pgp-signature, inline)]

Message #348 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 26 Nov 2006 19:01:03 +0200 (MET DST)

On Sun, 26 Nov 2006, Frans Pop wrote:
> On Sunday 26 November 2006 02:13, you wrote:
> > Could you please also test that whether Vista boots if you remove
> > /pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in
> > Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage
> > Or use a LiveCD which has both. The above page lists several of them.
> 
> Used ntfs-3g for this, but Vista still refuses to boot.

Hmm. What ntfs-3g version did you use? Only the latest, ntfs-3g 0.20061115 
is fully safe regards to umounting before reboot. Do you remember if you 
umounted the partition before reboot and did a 'sync'? An unclean unmount 
could cause the problem you have seen with earlier ntfs-3g versions, though
this is absolutely not typical.

> But.... progress!
> 
> I've managed to boot Vista using the following procedure (which I found by 
> accident when ntfs-3g complained about not being able to mount the NTFS 
> partition):
> - resize Vista partition
> - reboot into Vista (which fails at the point we all know so well by now)
>   Vista marks the boot as unsuccessful (next boot it will offer the safe
>   boot option, but still not run chkdsk by itself)
> - reboot into linux
> - (try mounting the partition using ntfs-3g which fails)
> - run ntfsfix
> - reboot into Vista, this will at last run chkdsk!
> - Vista reboots automatically after the chkdsk and this time successfully!
> 
> So, what does ntfsfix do on a ntfs volume marked "dirty" by Vista that 
> ntfsresize does not?

Nothing. The volume wasn't mountable because either it wasn't cleanly 
shutdown or because Vista made some changes when you booted.

Could you please try

	resize
	ntfsfix
	vista boot
and 
	resize
	mount
	delete /pagefile.sys
	umount 
	ntfsfix
	vista boot

> # ntfsfix /dev/sda1
> Mounting volume... FAILED
> Attempting to correct errors...
> Processing $FMT amd $MFTMirr...
> Reading $MFT... OK
> Reading $MFTMirr... OK
> Comparing $MFTMirr to $MFT... OK
> Processing of $MFT and $MFTMirr completed successfully.
> Setting required flags on partition... OK
> Going to empty the journal ($Logfile)... OK
> NTFS volume version is 3.1.
> NTFS partition /dev/sda1 was processed successfully.
> 
> Attached 3 screenshots that show Vista's chkdsk output.

Thanks, no strange thing here.

Cheers,
	Szaka

Message #353 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 14:17:07 +0000

On Sun, 2006-11-26 at 17:41 +0100, Frans Pop wrote:
> On Sunday 26 November 2006 02:13, you wrote:
> > Could you please also test that whether Vista boots if you remove
> > /pagefile.sys after ntfsresize? You can use ntfs-3g for this, it's in
> > Debian unstable. Usage: http://www.ntfs-3g.org/index.html#usage
> > Or use a LiveCD which has both. The above page lists several of them.
> 
> Used ntfs-3g for this, but Vista still refuses to boot.
> 
> But.... progress!
> 
> I've managed to boot Vista using the following procedure (which I found by 
> accident when ntfs-3g complained about not being able to mount the NTFS 
> partition):
> - resize Vista partition
> - reboot into Vista (which fails at the point we all know so well by now)
>   Vista marks the boot as unsuccessful (next boot it will offer the safe
>   boot option, but still not run chkdsk by itself)

I do not get the safe boot offer from Vista - but I resized a data
partition rather than the system partition...

> - reboot into linux
> - (try mounting the partition using ntfs-3g which fails)

I did not do this.

> - run ntfsfix
> - reboot into Vista, this will at last run chkdsk!
> - Vista reboots automatically after the chkdsk and this time successfully!

Yes, same here.

> So, what does ntfsfix do on a ntfs volume marked "dirty" by Vista that 
> ntfsresize does not?

Nothing!  In particular I found that running ntfsresize followed by
ntfsfix still causes the same vista boot problem.  Then running ntfsfix
again and booting vista again causes chkdsk to run and vista to work.
So it is not what ntfsfix does but the need to do it twice with a failed
vista boot in-between.

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #358 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 15:34:48 +0100

[Message part 1 (text/plain, inline)]

On Monday 27 November 2006 15:17, you wrote:
> Nothing!  In particular I found that running ntfsresize followed by
> ntfsfix still causes the same vista boot problem.  Then running ntfsfix
> again and booting vista again causes chkdsk to run and vista to work.
> So it is not what ntfsfix does but the need to do it twice with a
> failed vista boot in-between.

That's not how I see it...
ntfsfix behaves differently when it is run _after_ the failed Vista boot 
*because Vista marks the partition dirty*, but it is still ntfsfix 
that "fixes" the real problem which triggers Vista to run chkdsk on its 
next boot.
If you run ntfsfix after the resize, but _before_ booting Vista, it 
effectively does nothing as the partition is not marked "dirty".

[Message part 2 (application/pgp-signature, inline)]

Message #363 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 15:27:05 +0000

On Mon, 2006-11-27 at 15:34 +0100, Frans Pop wrote:
> On Monday 27 November 2006 15:17, you wrote:
> > Nothing!  In particular I found that running ntfsresize followed by
> > ntfsfix still causes the same vista boot problem.  Then running ntfsfix
> > again and booting vista again causes chkdsk to run and vista to work.
> > So it is not what ntfsfix does but the need to do it twice with a
> > failed vista boot in-between.
> 
> That's not how I see it...
> ntfsfix behaves differently when it is run _after_ the failed Vista boot 
> *because Vista marks the partition dirty*, but it is still ntfsfix 
> that "fixes" the real problem which triggers Vista to run chkdsk on its 
> next boot.
> If you run ntfsfix after the resize, but _before_ booting Vista, it 
> effectively does nothing as the partition is not marked "dirty".

That is wrong.  It always does the same thing no matter what the
partition is marked as...  Trust me, I wrote it so I should know!  (-:

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #368 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 19:55:16 +0100

[Message part 1 (text/plain, inline)]

On Monday 27 November 2006 16:27, Anton Altaparmakov wrote:
> That is wrong.  It always does the same thing no matter what the
> partition is marked as...  Trust me, I wrote it so I should know!  (-:

Oh, I trust you. However, that still does not explain what I see 
happening.

Directly after ntfsresize:
# ntfsfix /dev/sda1
Mounting volume... OK
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.

Boot Vista, which fails; reboot into linux:
# ntfsfix /dev/sda1
Mounting volume... FAILED
Attempting to correct errors...
Processing $FMT amd $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.

So, IMHO it _does_ different things, based on the fact that Vista leaves 
the partition "unmountable".

The differing bit being:
Attempting to correct errors...
Processing $FMT amd $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK
Processing of $MFT and $MFTMirr completed successfully.

And somehow, what ntfsfix does, makes Vista happy again, or at least happy 
enough that it is willing to run chkdsk.

So my conclusion (not hindered by any knowledge of NTFS or the inner 
workings of your excellent tools) is that if we (or rather you guys) can 
identify what ntfsfix does that makes Vista happy again, we may be able 
to solve this whole issue.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #373 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 20:44:04 +0000 (GMT)

On Mon, 27 Nov 2006, Frans Pop wrote:
> On Monday 27 November 2006 16:27, Anton Altaparmakov wrote:
> > That is wrong.  It always does the same thing no matter what the
> > partition is marked as...  Trust me, I wrote it so I should know!  (-:
> 
> Oh, I trust you. However, that still does not explain what I see 
> happening.
> 
> Directly after ntfsresize:
> # ntfsfix /dev/sda1
> Mounting volume... OK
> Setting required flags on partition... OK
> Going to empty the journal ($Logfile)... OK
> NTFS volume version is 3.1.
> NTFS partition /dev/sda1 was processed successfully.
> 
> Boot Vista, which fails; reboot into linux:
> # ntfsfix /dev/sda1
> Mounting volume... FAILED
> Attempting to correct errors...
> Processing $FMT amd $MFTMirr...
> Reading $MFT... OK
> Reading $MFTMirr... OK
> Comparing $MFTMirr to $MFT... OK
> Processing of $MFT and $MFTMirr completed successfully.
> Setting required flags on partition... OK
> Going to empty the journal ($Logfile)... OK
> NTFS volume version is 3.1.
> NTFS partition /dev/sda1 was processed successfully.
> 
> So, IMHO it _does_ different things, based on the fact that Vista leaves 
> the partition "unmountable".
> 
> The differing bit being:
> Attempting to correct errors...
> Processing $FMT amd $MFTMirr...
> Reading $MFT... OK
> Reading $MFTMirr... OK
> Comparing $MFTMirr to $MFT... OK
> Processing of $MFT and $MFTMirr completed successfully.
> 
> And somehow, what ntfsfix does, makes Vista happy again, or at least happy 
> enough that it is willing to run chkdsk.
> 
> So my conclusion (not hindered by any knowledge of NTFS or the inner 
> workings of your excellent tools) is that if we (or rather you guys) can 
> identify what ntfsfix does that makes Vista happy again, we may be able 
> to solve this whole issue.

Sorry it does explain it perfectly well.  The only reason you see a 
difference in output is that in first case volume is clean thus the 
internal libntfs mount succeeds and in second case it fails so ntfsfix 
does it by hand.  As you can see all its checking passes with OK thus it 
does not do anything at all in those functions.  The only place where it 
actually modifies the volume are:

<quote>
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
</quote>

And as you can see both outputs are identical thus the changes done to 
the volume are identical.  Sorry to disappoint you...

If you really do not believe me do this:

ntfsresize
ntfsfix		***1
ntfsfix		***2
boot vista	<- will fail
ntfsfix		***3
boot vista	<- will work

Note ***1 is what you did before, it will mark the volume dirty thus when 
you do ***2 it will fail to mount and do EXACTLY the same thing as ***3.  
You will notice the 100% identical output of ***2 and ***3...  Perhaps now 
you will believe me that ntfsfix is not in fact fixing the volume at 
all...

The explanation why vista is fixed the second time round I assume is along 
the lines of "first time round vista makes some modifications to itself 
then crashes", and second time round "the modifications from last boot 
together with the set chkdsk flag cause vista to work this time round".

Whether it has something to do with the boot cache or not I do not know 
but it certainly is NOT as simple as ntfsfix doing something different 
after the vista crash to what it did before.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #378 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 08:01:30 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

No, this does unfortunately not make Vista boot for me. :-(

Cheers,
Andree

On Sat, 2006-11-25 at 04:03 +0200, Szakacsits Szabolcs wrote:
> Hi,
> 
> Could you please try this after running ntfsresize and before booting 
> Vista:
> 
>   dd if=<PARTITION> bs=512 count=1 | dd of=<PARTITION> seek=<LAST_SECTOR>
> 
> where <LAST_SECTOR> is the last sector on <PARTITION>. It can be calculated 
> by running 
> 
>   sfdisk -d <DISK> | grep <PARTITION> 
> 
> and then by subtracting 1 from the value of 'size'.
> 
> Please let me know if this makes Vista boot or not. 
> 
> Thanks,
> 	Szaka
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #383 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 22:50:10 +0100

[Message part 1 (text/plain, inline)]

On Monday 27 November 2006 21:44, you wrote:
> ntfsresize
> ntfsfix		***1
> ntfsfix		***2
> boot vista	<- will fail
> ntfsfix		***3
> boot vista	<- will work
>
> Note ***1 is what you did before, it will mark the volume dirty thus
> when you do ***2 it will fail to mount and do EXACTLY the same thing as
> ***3.

Nope. After resize:
# ntfsfix /dev/sda1
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.
# ntfsfix /dev/sda1
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($Logfile)... OK
NTFS volume version is 3.1.
NTFS partition /dev/sda1 was processed successfully.

(Note: I just see that I failed to include one line last time: 
the "Processing of..." one.)

So ***2 is not the same as ***3; it remains the same as ***1.
Again, I'm not saying you are wrong, but you've got to appreciate that I'm 
seeing this from a user's perspective. I see different output from 
ntfsfix, and so logically assume that if it's not showing some steps, 
it's not executing those steps.

Are you really saying that the following lines are just empty and 
meaningless output?
Attempting to correct errors...
Processing $FMT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... OK

At the very least the mount check gives a different result. And if I 
understand you and the results above correctly, the volume being "dirty" 
and "unmountable" may be two different things. How does ntfsfix check if 
the volume is mountable or not?

> The explanation why vista is fixed the second time round I assume is
> along the lines of "first time round vista makes some modifications to
> itself then crashes", and second time round "the modifications from
> last boot together with the set chkdsk flag cause vista to work this
> time round".

I'm happy to accept this. So, let's concentrate on trying to find out what 
those changes are...

I don't know what Vista does exactly to make it unmountable or what other 
things it may do at the same time but ntfsfix definitely does do 
*something* after Vista has made the volume unmountable that results in 
Vista being happy again.
After all, if I try booting Vista a second time after it has failed the 
first time, it will just fail in exactly the same way as the first time.

I'll also be happy to provide additional images or whatever if needed, but 
IMO this still is the most concrete pointer we've gotten so far. As a 
user I _do_ need your expertise and guidance for the next step. I can 
only tell you what I'm seeing.

(using ntfsfix 1.13.1; libntfs 9:0:0)

[Message part 2 (application/pgp-signature, inline)]

Message #388 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 27 Nov 2006 22:45:26 +0000 (GMT)

On Mon, 27 Nov 2006, Frans Pop wrote:
> On Monday 27 November 2006 21:44, you wrote:
> > ntfsresize
> > ntfsfix		***1
> > ntfsfix		***2
> > boot vista	<- will fail
> > ntfsfix		***3
> > boot vista	<- will work
> >
> > Note ***1 is what you did before, it will mark the volume dirty thus
> > when you do ***2 it will fail to mount and do EXACTLY the same thing as
> > ***3.
> 
> Nope. After resize:
> # ntfsfix /dev/sda1
> Mounting volume... OK
> Processing of $MFT and $MFTMirr completed successfully.
> Setting required flags on partition... OK
> Going to empty the journal ($Logfile)... OK
> NTFS volume version is 3.1.
> NTFS partition /dev/sda1 was processed successfully.
> # ntfsfix /dev/sda1
> Mounting volume... OK
> Processing of $MFT and $MFTMirr completed successfully.
> Setting required flags on partition... OK
> Going to empty the journal ($Logfile)... OK
> NTFS volume version is 3.1.
> NTFS partition /dev/sda1 was processed successfully.
> 
> (Note: I just see that I failed to include one line last time: 
> the "Processing of..." one.)
> 
> So ***2 is not the same as ***3; it remains the same as ***1.
> Again, I'm not saying you are wrong, but you've got to appreciate that I'm 
> seeing this from a user's perspective. I see different output from 
> ntfsfix, and so logically assume that if it's not showing some steps, 
> it's not executing those steps.

Now I am confused why you see this like that.  Would you mind checking out 
ntfsprogs from CVS?  The needed commands/repositories are in detail to be 
found at (includes build instructions):

http://wiki.linux-ntfs.org/doku.php?id=howto:cvs

Could you run the ntfsfix from there and see if that makes a difference?

If it still gives you the same output as above then simply edit 
ntfsprogs/ntfsprogs/ntfsfix.c at line 538 where it says:

	/* Attempt a full mount first. */
        ntfs_log_info("Mounting volume... ");
        vol = ntfs_mount(opt.volume, 0);

and change that last line to say:

        //vol = ntfs_mount(opt.volume, 0);
        vol = NULL;

This will force the second code path to be taken which is what happens 
when the mount fails which is what you get after vista crashes...

> Are you really saying that the following lines are just empty and 
> meaningless output?
> Attempting to correct errors...
> Processing $FMT and $MFTMirr...
> Reading $MFT... OK
> Reading $MFTMirr... OK
> Comparing $MFTMirr to $MFT... OK

Yes they are.  (-:  If they actually did any changes to the volume, for 
each change you would get a line like this:

Correcting differences in $MFT record %d...
or
Correcting differences in $MFTMirr record %d...

Where %d would be the mft/mftmirror record number being corrected.

As you do not see any such lines it means that the verification is a 
success and no changes are made.

> At the very least the mount check gives a different result. And if I 
> understand you and the results above correctly, the volume being "dirty" 
> and "unmountable" may be two different things. How does ntfsfix check if 
> the volume is mountable or not?

It tries to mount it!  And if it fails, it does it by hand...

> > The explanation why vista is fixed the second time round I assume is
> > along the lines of "first time round vista makes some modifications to
> > itself then crashes", and second time round "the modifications from
> > last boot together with the set chkdsk flag cause vista to work this
> > time round".
> 
> I'm happy to accept this. So, let's concentrate on trying to find out what 
> those changes are...
> 
> I don't know what Vista does exactly to make it unmountable or what other 
> things it may do at the same time but ntfsfix definitely does do 
> *something* after Vista has made the volume unmountable that results in 
> Vista being happy again.
> After all, if I try booting Vista a second time after it has failed the 
> first time, it will just fail in exactly the same way as the first time.
> 
> I'll also be happy to provide additional images or whatever if needed, but 
> IMO this still is the most concrete pointer we've gotten so far. As a 
> user I _do_ need your expertise and guidance for the next step. I can 
> only tell you what I'm seeing.

Try the ntfsfix from CVS and then edit the ntfsfix.c source and recompile 
so it forces it to fail the mount and do it by hand.  Then run the 
modified ntfsfix after ntfsresize and boot Vista.  I am betting that Vista 
will still fail to boot even though ntfsfix did exactly the same thing as 
it does after Vista fails to boot.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #393 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 02:56:02 +0100

[Message part 1 (text/plain, inline)]

On Monday 27 November 2006 23:45, Anton Altaparmakov wrote:
>         //vol = ntfs_mount(opt.volume, 0);
>         vol = NULL;

I'm almost afraid to have to tell you this... ;-)

After recompiling ntfsfix with this change, running it once immediately 
after the ntfsresize and rebooting Vista, I _do_ get the chkdsk by Vista 
and it boots fine after its automatic reboot.

So, it very much looks like there is something in the "mount failed" 
codepath after all.

I've tried this trick with both your CVS version and with the current 
version in Debian, both with identical results.

I just noticed something.
If the mount is OK, ntfsfix prints all its messages almost instantaneous, 
like nothing is actually happening at all. But if the mount fails, 
ntfsfix takes significantly longer, especially over the "Going to empty 
the journal ($logfile)" step.
There is a definite pause, both while that step is being processed 
(before "OK\n" is printed) and immediately afterwards (before the next 
line "NTFS volume version" is printed).

Another step closer...

[Message part 2 (application/pgp-signature, inline)]

Message #398 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 10:14:27 +0000

On Tue, 2006-11-28 at 02:56 +0100, Frans Pop wrote:
> On Monday 27 November 2006 23:45, Anton Altaparmakov wrote:
> >         //vol = ntfs_mount(opt.volume, 0);
> >         vol = NULL;
> 
> I'm almost afraid to have to tell you this... ;-)
> 
> After recompiling ntfsfix with this change, running it once immediately 
> after the ntfsresize and rebooting Vista, I _do_ get the chkdsk by Vista 
> and it boots fine after its automatic reboot.
> 
> So, it very much looks like there is something in the "mount failed" 
> codepath after all.
> 
> I've tried this trick with both your CVS version and with the current 
> version in Debian, both with identical results.
> 
> I just noticed something.
> If the mount is OK, ntfsfix prints all its messages almost instantaneous, 
> like nothing is actually happening at all. But if the mount fails, 
> ntfsfix takes significantly longer, especially over the "Going to empty 
> the journal ($logfile)" step.
> There is a definite pause, both while that step is being processed 
> (before "OK\n" is printed) and immediately afterwards (before the next 
> line "NTFS volume version" is printed).
> 
> Another step closer...

Argh!  Thank you for persisting with this.  I have now looked at the
code and you are right it does not do the same thing.  This is because
when Yura ported my $LogFile code from the kernel for some unknown to me
(or forgotten by me) reason he did not integrate clearing the journal
into the mount process.  He integrated the checking but not the
clearing.  This is a HUGE and VERY BAD bug in libntfs and means that all
ntfs utilities are _DANGEROUS_ to run and can cause massive and very
hard to detect data corruption.  )-:

No wonder Vista does not boot!!!  It is amazing it took so long to find
this problem.  I cannot believe we managed to get away with it for so
long...

I have now fixed this in CVS.  Could you update, compile, and try again?

Once just with ntfsresize (the one in current CVS) and if that still
does not work, once with ntfsresize + immediate ntfsfix (the one in
current CVS without the my change that you put in).  If that still does
not fix it then once with ntfsresize + immediate ntfsfix (the one in
current CVS but with my change that you put in again).

In an ideal world, just ntfsresize will now be sufficient.  If not
ntfsfix should work first time.  And if not I need to look at it
further!

Thanks!

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #403 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 11:07:12 +0000

On Tue, 2006-11-28 at 10:14 +0000, Anton Altaparmakov wrote:
> On Tue, 2006-11-28 at 02:56 +0100, Frans Pop wrote:
> > On Monday 27 November 2006 23:45, Anton Altaparmakov wrote:
> > >         //vol = ntfs_mount(opt.volume, 0);
> > >         vol = NULL;
> > 
> > I'm almost afraid to have to tell you this... ;-)
> > 
> > After recompiling ntfsfix with this change, running it once immediately 
> > after the ntfsresize and rebooting Vista, I _do_ get the chkdsk by Vista 
> > and it boots fine after its automatic reboot.
> > 
> > So, it very much looks like there is something in the "mount failed" 
> > codepath after all.
> > 
> > I've tried this trick with both your CVS version and with the current 
> > version in Debian, both with identical results.
> > 
> > I just noticed something.
> > If the mount is OK, ntfsfix prints all its messages almost instantaneous, 
> > like nothing is actually happening at all. But if the mount fails, 
> > ntfsfix takes significantly longer, especially over the "Going to empty 
> > the journal ($logfile)" step.
> > There is a definite pause, both while that step is being processed 
> > (before "OK\n" is printed) and immediately afterwards (before the next 
> > line "NTFS volume version" is printed).
> > 
> > Another step closer...
> 
> Argh!  Thank you for persisting with this.  I have now looked at the
> code and you are right it does not do the same thing.  This is because
> when Yura ported my $LogFile code from the kernel for some unknown to me
> (or forgotten by me) reason he did not integrate clearing the journal
> into the mount process.  He integrated the checking but not the
> clearing.  This is a HUGE and VERY BAD bug in libntfs and means that all
> ntfs utilities are _DANGEROUS_ to run and can cause massive and very
> hard to detect data corruption.  )-:
> 
> No wonder Vista does not boot!!!  It is amazing it took so long to find
> this problem.  I cannot believe we managed to get away with it for so
> long...
> 
> I have now fixed this in CVS.  Could you update, compile, and try again?
> 
> Once just with ntfsresize (the one in current CVS) and if that still
> does not work, once with ntfsresize + immediate ntfsfix (the one in
> current CVS without the my change that you put in).  If that still does
> not fix it then once with ntfsresize + immediate ntfsfix (the one in
> current CVS but with my change that you put in again).
> 
> In an ideal world, just ntfsresize will now be sufficient.  If not
> ntfsfix should work first time.  And if not I need to look at it
> further!

Ok, I just committed some more fixes to ntfsresize.  It never actually
unmounted the volume, just exited which was very rude of it!

Using the latest ntfsresize/libntfs combination on my Vista data
partition I can now run ntfsresize to change the size of a partition
then immediately run Vista and it boots, runs chkdsk automatically, and
then continues to boot to completion.  Yey.  (-:

Frans, it would be great if you could verify it is fixed for you when
resizing the system partition also.  Assuming you say it works I think
it is time for a new ntfsprogs release which we can rubber stamp as
"Vista compatible".  (-:

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #408 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 12:46:42 +0100 (MET)

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:

> Ok, I just committed some more fixes to ntfsresize.  It never actually
> unmounted the volume, just exited which was very rude of it!

It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
dangerous to umount because that could interfer, corrupt or destroy the
resized, consistent NTFS.

	Szaka

Message #413 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 11:54:01 +0000

Hi Szaka,

On Tue, 2006-11-28 at 12:46 +0100, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> 
> > Ok, I just committed some more fixes to ntfsresize.  It never actually
> > unmounted the volume, just exited which was very rude of it!
> 
> It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
> dangerous to umount because that could interfer, corrupt or destroy the
> resized, consistent NTFS.

Do you not keep the "ntfs_volume" of the mount consistent with your
changes?  If yes you should umount and it is not dangerous.  If not why
not?

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #418 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 13:08:26 +0100 (MET)

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:

> > It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
> > dangerous to umount because that could interfer, corrupt or destroy the
> > resized, consistent NTFS.
> 
> Do you not keep the "ntfs_volume" of the mount consistent with your
> changes?  If yes you should umount and it is not dangerous.  If not why
> not?

There are two NTFS during resizing. The original and the resized. When 
the resizing is over then the latter is consistent and the old one is
irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
umount. It works like: mount and morph the original into a new one.

	Szaka

Message #423 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 12:44:44 +0000

On Tue, 2006-11-28 at 13:08 +0100, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> 
> > > It's intentionally not umounted. Ntfsresize __rewrites__ NTFS and it's
> > > dangerous to umount because that could interfer, corrupt or destroy the
> > > resized, consistent NTFS.
> > 
> > Do you not keep the "ntfs_volume" of the mount consistent with your
> > changes?  If yes you should umount and it is not dangerous.  If not why
> > not?
> 
> There are two NTFS during resizing. The original and the resized. When 
> the resizing is over then the latter is consistent and the old one is
> irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
> umount. It works like: mount and morph the original into a new one.

Looking at the source code, you appear to be holding the ntfs_volume in
your "resize" structure and then use it everywhere to write to the
volume.

For example you keep calling write_mft_record() which just calls the
libntfs provided ntfs_mft_record_write()...

So you better have that ntfs_volume be a consistent view of the volume
at any point in time or things will break anyway...

I cannot see anywhere you having two different ntfs_volume structures.
Apologies if I have missed it.  Perhaps you can point out the code to me
where you have two volumes as I cannot see it...

However, given things still work, and given that ntfsresize now works
for Vista for me when it did not do so before I would say unmounting is
both safe and required for ntfsresize.  (-;

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #428 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Thierry Vignaud <tvignaud@mandriva.com>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: Bug#379628: Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 14:19:12 +0100

Anton Altaparmakov <aia21@cam.ac.uk> writes:

> Argh!  Thank you for persisting with this.  I have now looked at the
> code and you are right it does not do the same thing.  This is
> because when Yura ported my $LogFile code from the kernel for some
> unknown to me (or forgotten by me) reason he did not integrate
> clearing the journal into the mount process.  He integrated the
> checking but not the clearing.  This is a HUGE and VERY BAD bug in
> libntfs and means that all ntfs utilities are _DANGEROUS_ to run and
> can cause massive and very hard to detect data corruption.  )-:

will there be a new release with that fix?

> No wonder Vista does not boot!!!  It is amazing it took so long to
> find this problem.  I cannot believe we managed to get away with it
> for so long...

Message #433 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: linux-ntfs-dev@lists.sf.net, 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 14:20:22 +0100 (MET)

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> On Tue, 2006-11-28 at 13:08 +0100, Szakacsits Szabolcs wrote:
> > 
> > There are two NTFS during resizing. The original and the resized. When 
> > the resizing is over then the latter is consistent and the old one is
> > irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
> > umount. It works like: mount and morph the original into a new one.
[...] 
> I cannot see anywhere you having two different ntfs_volume structures.
> Apologies if I have missed it.  Perhaps you can point out the code to me
> where you have two volumes as I cannot see it...

relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
strict order in what and when is relocated. At some point ntfs_volume is
mostly used only for reading and a new NTFS gets written. 

Anything must be modified before it gets relocated, never afterwards. 
Your change broke this very serious rule.

> However, given things still work, and given that ntfsresize now works
> for Vista for me when it did not do so before I would say unmounting is
> both safe and required for ntfsresize.  (-;

There is a huge difference between the "works for me" and "always works".

	Szaka

Message #438 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 13:47:36 +0000

On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> > On Tue, 2006-11-28 at 13:08 +0100, Szakacsits Szabolcs wrote:
> > > 
> > > There are two NTFS during resizing. The original and the resized. When 
> > > the resizing is over then the latter is consistent and the old one is
> > > irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
> > > umount. It works like: mount and morph the original into a new one.
> [...] 
> > I cannot see anywhere you having two different ntfs_volume structures.
> > Apologies if I have missed it.  Perhaps you can point out the code to me
> > where you have two volumes as I cannot see it...
> 
> relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
> strict order in what and when is relocated. At some point ntfs_volume is
> mostly used only for reading and a new NTFS gets written.

That is not true, at least not in the code that I am reading here!  It
may have been your intention perhaps but you failed to code it...

Look:

relocate_inodes() -> relocate_inode() -> at the end of the function
calls write_mft_record() which uses the ntfs_volume and the libntfs
function ntfs_mft_record_write() to do the writing.

After that we have truncate_badclust_file() and truncate_bitmap_file()
both of which use write_mft_record() also...

After that we have update_bootsector() and then ntfsresize is finished.

So the only thing that does not use the ntfs_volume for writing is the
final update_bootsector() call...

If you consider it safe to call ntfs_mft_record_write() right until the
end of ntfsresize execution you must also consider it safe to unmount
the volume up to that point.

What am I missing?

> Anything must be modified before it gets relocated, never afterwards. 
> Your change broke this very serious rule.

Yes, and I do not see anything wrong with that.  ntfsresize should keep
the ntfs_volume in sync at all times and then it can be safely
unmounted.  If it does not do that than ntfsresize is arguably broken by
design.

Remember that what you were doing was not working for Vista and it works
now...

Anyway, given ntfsresize is your code, if you want to insist on not
allowing unmounting, then can you please tell me the exact point in the
code at which unmounting becomes dangerous/wrong and we can turn it off
at that point by simply doing "g_vol = NULL;" in the code at that point.

>From what you have said so far that point in time should be the call to
prepare_volume_fixup(), do you agree?

If yes, then simply adding g_vol = NULL; to the end of
prepare_volume_fixup() would do the trick...

I have done this now (see CVS).  Happy now?  (-:

> > However, given things still work, and given that ntfsresize now works
> > for Vista for me when it did not do so before I would say unmounting is
> > both safe and required for ntfsresize.  (-;
> 
> There is a huge difference between the "works for me" and "always works".

Certainly but given it was broken to start with "works for me" and
"never works for Vista" is more like the real comparison here and the
"works for me" is a big improvement...  (-;

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #443 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 13:57:47 +0000

I can confirm that the latest CVS with my change to disable unmounting
during prepare_volume_fixup() still works for me with Vista on a data
partition being resized.

Best regards,

	Anton

On Tue, 2006-11-28 at 13:47 +0000, Anton Altaparmakov wrote:
> On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> > On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> > > On Tue, 2006-11-28 at 13:08 +0100, Szakacsits Szabolcs wrote:
> > > > 
> > > > There are two NTFS during resizing. The original and the resized. When 
> > > > the resizing is over then the latter is consistent and the old one is
> > > > irrelevant. ntfsresize doesn't work like the other utilities: mount, modify,
> > > > umount. It works like: mount and morph the original into a new one.
> > [...] 
> > > I cannot see anywhere you having two different ntfs_volume structures.
> > > Apologies if I have missed it.  Perhaps you can point out the code to me
> > > where you have two volumes as I cannot see it...
> > 
> > relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
> > strict order in what and when is relocated. At some point ntfs_volume is
> > mostly used only for reading and a new NTFS gets written.
> 
> That is not true, at least not in the code that I am reading here!  It
> may have been your intention perhaps but you failed to code it...
> 
> Look:
> 
> relocate_inodes() -> relocate_inode() -> at the end of the function
> calls write_mft_record() which uses the ntfs_volume and the libntfs
> function ntfs_mft_record_write() to do the writing.
> 
> After that we have truncate_badclust_file() and truncate_bitmap_file()
> both of which use write_mft_record() also...
> 
> After that we have update_bootsector() and then ntfsresize is finished.
> 
> So the only thing that does not use the ntfs_volume for writing is the
> final update_bootsector() call...
> 
> If you consider it safe to call ntfs_mft_record_write() right until the
> end of ntfsresize execution you must also consider it safe to unmount
> the volume up to that point.
> 
> What am I missing?
> 
> > Anything must be modified before it gets relocated, never afterwards. 
> > Your change broke this very serious rule.
> 
> Yes, and I do not see anything wrong with that.  ntfsresize should keep
> the ntfs_volume in sync at all times and then it can be safely
> unmounted.  If it does not do that than ntfsresize is arguably broken by
> design.
> 
> Remember that what you were doing was not working for Vista and it works
> now...
> 
> Anyway, given ntfsresize is your code, if you want to insist on not
> allowing unmounting, then can you please tell me the exact point in the
> code at which unmounting becomes dangerous/wrong and we can turn it off
> at that point by simply doing "g_vol = NULL;" in the code at that point.
> 
> >From what you have said so far that point in time should be the call to
> prepare_volume_fixup(), do you agree?
> 
> If yes, then simply adding g_vol = NULL; to the end of
> prepare_volume_fixup() would do the trick...
> 
> I have done this now (see CVS).  Happy now?  (-:
> 
> > > However, given things still work, and given that ntfsresize now works
> > > for Vista for me when it did not do so before I would say unmounting is
> > > both safe and required for ntfsresize.  (-;
> > 
> > There is a huge difference between the "works for me" and "always works".
> 
> Certainly but given it was broken to start with "works for me" and
> "never works for Vista" is more like the real comparison here and the
> "works for me" is a big improvement...  (-;
> 
> Best regards,
> 
>         Anton
Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #448 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 16:54:21 +0100

[Message part 1 (text/plain, inline)]

On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
> There are two NTFS during resizing. The original and the resized. When
> the resizing is over then the latter is consistent and the old one is
> irrelevant. ntfsresize doesn't work like the other utilities: mount,
> modify, umount. It works like: mount and morph the original into a new
> one.

I'm going to wait with further testing until you have sorted out this 
difference of opinion.

I guess that in this context "being mounted" is something different than 
the filesystem being mounted from a linux filesystem point of view?

Szakacsits' statements do make me wonder though what happens if you do 
(try to) mount/unmount a resized NTFS partition after resizing it, maybe 
using the available "force" options.

It also makes me wonder what happens when linux is shut down. Does it get 
unmounted then after all or is that not relevant as the partition is not 
mounted from a linux point of view?

[Message part 2 (application/pgp-signature, inline)]

Message #453 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 17:18:12 +0100 (MET)

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> > 
> > relocate_inodes(), relocate_inode(), especially the $MFT part. There is a
> > strict order in what and when is relocated. At some point ntfs_volume is
> > mostly used only for reading and a new NTFS gets written.
> 
> That is not true, at least not in the code that I am reading here!  It
> may have been your intention perhaps but you failed to code it...

Then it wouldn't have worked. 

> relocate_inodes() -> relocate_inode() -> at the end of the function
> calls write_mft_record() which uses the ntfs_volume and the libntfs
> function ntfs_mft_record_write() to do the writing.

Think about relocating $MFT.
 
> After that we have truncate_badclust_file() and truncate_bitmap_file()
> both of which use write_mft_record() also...

The beginning of the $MFT is never relocated, so the MFT records belonging
to these files can be safely modified in place, otherwise resizing is
restricted to a safe size.

> Remember that what you were doing was not working for Vista and it works
> now...

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?

You seem to mix here two different problems: the missing log file reset in
libntfs and the unsafe umount you introduced by another patch to ntfsresize
because you thought that it was missing by accident.
 
> Anyway, given ntfsresize is your code, if you want to insist on not
> allowing unmounting, then can you please tell me the exact point in the
> code at which unmounting becomes dangerous/wrong 

I must think about it. The design rule was being always consistent or
trivially recoverable whenever we exit immediately without any cleanup.

> > There is a huge difference between the "works for me" and "always works".
> 
> Certainly but given it was broken to start with "works for me" and
> "never works for Vista" is more like the real comparison here and the
> "works for me" is a big improvement...  (-;

The first patch seems to fixed Vista, the next one broke all of them in
certain scenarios.

	Szaka

Message #458 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 21:22:52 +0000 (GMT)

Hi,

Please note that the patch as it is has a very awkward side effect: Every 
time you run ntfsresize and either you answer "no" to the "really proceed" 
question or ntfsresize aborts without doing anything because it hits a 
"this is not supported" case or you try to resize to a too small size or 
anything like that the volume is left dirty thus running ntfsresize again 
then fails.  This is because ntfsresize does not unmount the volume.  My 
complete patches up to CVS head cause the unmounting to happen but only 
until all the checks have passed and ntfsresize is about to start 
migrating clusters around.  At that point, before the first modification 
happens, I turn off the unmounting and from then on ntfsresize will run 
and independent of when it is going to stop (abort or complete), it will 
no longer unmount like Szaka wants it to be.  Then the volume is left 
dirty which is what you want to happen anyway.

Best regards,

	Anton

On Tue, 28 Nov 2006, Carl-Daniel Hailfinger wrote:

> Hello Frans,
> hello Andree,
> 
> Frans Pop wrote:
> > On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
> >> There are two NTFS during resizing. The original and the resized. When
> >> the resizing is over then the latter is consistent and the old one is
> >> irrelevant. ntfsresize doesn't work like the other utilities: mount,
> >> modify, umount. It works like: mount and morph the original into a new
> >> one.
> > 
> > I'm going to wait with further testing until you have sorted out this 
> > difference of opinion.
> 
> Could you test the attached patches against ntfsprogs 1.13.1? It is my
> attempt at a backport for the first patch from Anton which seems to
> have agreement from Szaka.
> ntfsprogs-1.13.1-rename-MS_.diff is just a rename orgy to make
>  backporting easier and has to be applied first.
> ntfsprogs-1.13.1-vistahotfix.diff is a stripped version of Anton's
>  first patch.
> 
> Regards,
> Carl-Daniel
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #463 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 21:27:06 +0100

[Message part 1 (text/plain, inline)]

Hello Frans,
hello Andree,

Frans Pop wrote:
> On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
>> There are two NTFS during resizing. The original and the resized. When
>> the resizing is over then the latter is consistent and the old one is
>> irrelevant. ntfsresize doesn't work like the other utilities: mount,
>> modify, umount. It works like: mount and morph the original into a new
>> one.
> 
> I'm going to wait with further testing until you have sorted out this 
> difference of opinion.

Could you test the attached patches against ntfsprogs 1.13.1? It is my
attempt at a backport for the first patch from Anton which seems to
have agreement from Szaka.
ntfsprogs-1.13.1-rename-MS_.diff is just a rename orgy to make
 backporting easier and has to be applied first.
ntfsprogs-1.13.1-vistahotfix.diff is a stripped version of Anton's
 first patch.

Regards,
Carl-Daniel

[ntfsprogs-1.13.1-rename-MS_.diff (text/plain, inline)]

diff -urN ntfsprogs-1.13.1-orig/include/ntfs/volume.h ntfsprogs-1.13.1/include/ntfs/volume.h
--- ntfsprogs-1.13.1-orig/include/ntfs/volume.h	2006-01-08 16:53:28.000000000 +0100
+++ ntfsprogs-1.13.1/include/ntfs/volume.h	2006-11-28 19:39:22.000000000 +0100
@@ -41,25 +41,6 @@
 #include <mntent.h>
 #endif
 
-/*
- * Under Cygwin, DJGPP and FreeBSD we do not have MS_RDONLY and MS_NOATIME,
- * so we define them ourselves.
- */
-#ifndef MS_RDONLY
-#define MS_RDONLY 1
-#endif
-/*
- * Solaris defines MS_RDONLY but not MS_NOATIME thus we need to carefully
- * define MS_NOATIME.
- */
-#ifndef MS_NOATIME
-#if (MS_RDONLY != 1)
-#	define MS_NOATIME 1
-#else
-#	define MS_NOATIME 2
-#endif
-#endif
-
 /* Forward declaration */
 typedef struct _ntfs_volume ntfs_volume;
 
@@ -69,6 +50,12 @@
 #include "inode.h"
 #include "attrib.h"
 
+enum {
+	NTFS_MNT_RDONLY	 	= 1,
+	NTFS_MNT_NOATIME 	= 2,
+	NTFS_MNT_CASE_SENSITIVE	= 4,
+};
+
 /**
  * enum ntfs_mount_flags -
  *
diff -urN ntfsprogs-1.13.1-orig/libntfs/gnome-vfs-method.c ntfsprogs-1.13.1/libntfs/gnome-vfs-method.c
--- ntfsprogs-1.13.1-orig/libntfs/gnome-vfs-method.c	2006-02-03 23:19:19.000000000 +0100
+++ ntfsprogs-1.13.1/libntfs/gnome-vfs-method.c	2006-11-28 19:29:04.000000000 +0100
@@ -162,7 +162,7 @@
 			return GNOME_VFS_ERROR_INVALID_URI;
 		}
 
-		if (!(volume = ntfs_mount(uri->parent->text, MS_RDONLY))) {
+		if (!(volume = ntfs_mount(uri->parent->text, NTFS_MNT_RDONLY))) {
 			g_free(uri_parent_string);
 			return GNOME_VFS_ERROR_WRONG_FORMAT;
 		}
diff -urN ntfsprogs-1.13.1-orig/libntfs/volume.c ntfsprogs-1.13.1/libntfs/volume.c
--- ntfsprogs-1.13.1-orig/libntfs/volume.c	2006-03-28 00:43:09.000000000 +0200
+++ ntfsprogs-1.13.1/libntfs/volume.c	2006-11-28 19:29:48.000000000 +0100
@@ -429,9 +429,9 @@
 	}
 	ntfs_upcase_table_build(vol->upcase,
 			vol->upcase_len * sizeof(ntfschar));
-	if (flags & MS_RDONLY)
+	if (flags & NTFS_MNT_RDONLY)
 		NVolSetReadOnly(vol);
-	if (flags & MS_NOATIME)
+	if (flags & NTFS_MNT_NOATIME)
 		NVolSetNoATime(vol);
 	ntfs_log_debug("Reading bootsector... ");
 	if (dev->d_ops->open(dev, NVolReadOnly(vol) ? O_RDONLY: O_RDWR)) {
@@ -745,8 +745,8 @@
  * @flags is an optional second parameter. The same flags are used as for
  * the mount system call (man 2 mount). Currently only the following flags
  * are implemented:
- *	MS_RDONLY	- mount volume read-only
- *	MS_NOATIME	- do not update access time
+ *	NTFS_MNT_RDONLY	- mount volume read-only
+ *	NTFS_MNT_NOATIME	- do not update access time
  *
  * The function opens the device @dev and verifies that it contains a valid
  * bootsector. Then, it allocates an ntfs_volume structure and initializes
@@ -1116,7 +1116,7 @@
 	 * Check for dirty logfile and hibernated Windows.
 	 * We care only about read-write mounts.
 	 */
-	if (!(flags & MS_RDONLY)) {
+	if (!(flags & NTFS_MNT_RDONLY)) {
 		if (ntfs_volume_check_logfile(vol) < 0)
 			goto error_exit;
 		if (ntfs_volume_check_hiberfile(vol) < 0)
@@ -1148,8 +1148,8 @@
  * @flags is an optional second parameter. The same flags are used as for
  * the mount system call (man 2 mount). Currently only the following flags
  * are implemented:
- *	MS_RDONLY	- mount volume read-only
- *	MS_NOATIME	- do not update access time
+ *	NTFS_MNT_RDONLY	- mount volume read-only
+ *	NTFS_MNT_NOATIME	- do not update access time
  *
  * The function opens the device or file @name and verifies that it contains a
  * valid bootsector. Then, it allocates an ntfs_volume structure and initializes
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfscat.c ntfsprogs-1.13.1/ntfsprogs/ntfscat.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfscat.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfscat.c	2006-11-28 19:29:04.000000000 +0100
@@ -399,7 +399,7 @@
 
 	utils_set_locale();
 
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol) {
 		ntfs_log_perror("ERROR: couldn't mount volume");
 		return 1;
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsclone.c ntfsprogs-1.13.1/ntfsprogs/ntfsclone.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsclone.c	2006-06-21 09:59:19.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsclone.c	2006-11-28 19:29:48.000000000 +0100
@@ -1487,7 +1487,7 @@
 {
 	s64 device_size;
 
-	mount_volume(MS_RDONLY);
+	mount_volume(NTFS_MNT_RDONLY);
 
 	device_size = ntfs_device_size_get(vol->dev, 1);
 	if (device_size <= 0)
@@ -1716,7 +1716,7 @@
 	/* 'force' again mount for dirty volumes (e.g. after resize).
 	   FIXME: use mount flags to avoid potential side-effects in future */
 	opt.force++;
-	mount_volume(MS_NOATIME);
+	mount_volume(NTFS_MNT_NOATIME);
 
 	free(lcn_bitmap.bm);
 	setup_lcn_bitmap();
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfscluster.c ntfsprogs-1.13.1/ntfsprogs/ntfscluster.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfscluster.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfscluster.c	2006-11-28 19:29:04.000000000 +0100
@@ -492,7 +492,7 @@
 
 	utils_set_locale();
 
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol)
 		return 1;
 
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfscmp.c ntfsprogs-1.13.1/ntfsprogs/ntfscmp.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfscmp.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfscmp.c	2006-11-28 19:29:04.000000000 +0100
@@ -829,7 +829,7 @@
 				 "You must 'umount' it first.\n", volume);
 	}
 
-	vol = ntfs_mount(volume, MS_RDONLY);
+	vol = ntfs_mount(volume, NTFS_MNT_RDONLY);
 	if (vol == NULL) {
 
 		int err = errno;
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfscp.c ntfsprogs-1.13.1/ntfsprogs/ntfscp.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfscp.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfscp.c	2006-11-28 19:29:04.000000000 +0100
@@ -312,7 +312,7 @@
 	}
 
 	if (opts.noaction)
-		flags = MS_RDONLY;
+		flags = NTFS_MNT_RDONLY;
 
 	vol = utils_mount_volume(opts.device, flags, opts.force);
 	if (!vol) {
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsdecrypt.c ntfsprogs-1.13.1/ntfsprogs/ntfsdecrypt.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsdecrypt.c	2006-04-20 00:03:58.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsdecrypt.c	2006-11-28 19:29:04.000000000 +0100
@@ -1313,7 +1313,7 @@
 		return 1;
 	}
 	/* Mount the ntfs volume. */
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol) {
 		ntfs_log_error("Failed to mount ntfs volume.  Aborting.\n");
 		ntfs_rsa_private_key_release(rsa_key);
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsdump_logfile.c ntfsprogs-1.13.1/ntfsprogs/ntfsdump_logfile.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsdump_logfile.c	2005-11-20 15:15:33.000000000 +0100
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsdump_logfile.c	2006-11-28 19:29:04.000000000 +0100
@@ -197,7 +197,7 @@
 		ntfs_inode *ni;
 		ntfs_attr *na;
 
-		vol = ntfs_mount(filename, MS_RDONLY);
+		vol = ntfs_mount(filename, NTFS_MNT_RDONLY);
 		if (!vol)
 			log_err_exit(NULL, "Failed to mount %s: %s\n",
 					filename, strerror(errno));
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsinfo.c ntfsprogs-1.13.1/ntfsprogs/ntfsinfo.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsinfo.c	2006-05-20 23:27:15.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsinfo.c	2006-11-28 19:29:04.000000000 +0100
@@ -1967,7 +1967,7 @@
 
 	utils_set_locale();
 
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol)
 		return 1;
 
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfslabel.c ntfsprogs-1.13.1/ntfsprogs/ntfslabel.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfslabel.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfslabel.c	2006-11-28 19:29:04.000000000 +0100
@@ -394,7 +394,7 @@
 	if (!opts.label)
 		opts.noaction++;
 
-	vol = utils_mount_volume(opts.device, opts.noaction ? MS_RDONLY : 0,
+	vol = utils_mount_volume(opts.device, opts.noaction ? NTFS_MNT_RDONLY : 0,
 			opts.force);
 	if (!vol)
 		return 1;
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsls.c ntfsprogs-1.13.1/ntfsprogs/ntfsls.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsls.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsls.c	2006-11-28 19:29:04.000000000 +0100
@@ -651,7 +651,7 @@
 
 	utils_set_locale();
 
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol) {
 		// FIXME: Print error... (AIA)
 		return 2;
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmftalloc.c ntfsprogs-1.13.1/ntfsprogs/ntfsmftalloc.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmftalloc.c	2005-11-20 15:15:33.000000000 +0100
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsmftalloc.c	2006-11-28 19:29:04.000000000 +0100
@@ -313,7 +313,7 @@
 	/* Mount the device. */
 	if (opts.no_action) {
 		ntfs_log_quiet("Running in READ-ONLY mode!\n");
-		ul = MS_RDONLY;
+		ul = NTFS_MNT_RDONLY;
 	} else
 		ul = 0;
 	vol = ntfs_mount(dev_name, ul);
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmount.c ntfsprogs-1.13.1/ntfsprogs/ntfsmount.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmount.c	2006-05-19 06:22:53.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsmount.c	2006-11-28 19:29:48.000000000 +0100
@@ -1420,8 +1420,8 @@
 {
 	ntfs_volume *vol;
 
-	vol = utils_mount_volume(device, ((ctx->ro) ? MS_RDONLY : 0) |
-			((ctx->noatime) ? MS_NOATIME : 0), ctx->force);
+	vol = utils_mount_volume(device, ((ctx->ro) ? NTFS_MNT_RDONLY : 0) |
+			((ctx->noatime) ? NTFS_MNT_NOATIME : 0), ctx->force);
 	if (!vol) {
 		ntfs_log_error("Mount failed.\n");
 		return -1;
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmove.c ntfsprogs-1.13.1/ntfsprogs/ntfsmove.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsmove.c	2006-04-05 14:43:07.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsmove.c	2006-11-28 19:29:05.000000000 +0100
@@ -873,7 +873,7 @@
 	utils_set_locale();
 
 	if (opts.noaction)
-		flags |= MS_RDONLY;
+		flags |= NTFS_MNT_RDONLY;
 
 	vol = utils_mount_volume(opts.device, flags, opts.force);
 	if (!vol) {
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsresize.c ntfsprogs-1.13.1/ntfsprogs/ntfsresize.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsresize.c	2006-04-19 00:03:09.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsresize.c	2006-11-28 19:29:48.000000000 +0100
@@ -486,7 +486,7 @@
 			opt.info++;
 			break;
 		case 'n':
-			opt.ro_flag = MS_RDONLY;
+			opt.ro_flag = NTFS_MNT_RDONLY;
 			break;
 		case 'P':
 			opt.show_progress = 0;
@@ -522,7 +522,7 @@
 			err++;
 		}
 		if (opt.info) {
-			opt.ro_flag = MS_RDONLY;
+			opt.ro_flag = NTFS_MNT_RDONLY;
 			if (opt.bytes) {
 				printf(NERR_PREFIX "Options --info and --size "
 					"can't be used together.\n");
@@ -2238,7 +2238,7 @@
 				 "You must 'umount' it first.\n", opt.volume);
 	}
 
-	if (!(vol = ntfs_mount(opt.volume, opt.ro_flag | MS_NOATIME))) {
+	if (!(vol = ntfs_mount(opt.volume, opt.ro_flag | NTFS_MNT_NOATIME))) {
 
 		int err = errno;
 
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsrm.c ntfsprogs-1.13.1/ntfsprogs/ntfsrm.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsrm.c	2006-04-05 14:43:08.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsrm.c	2006-11-28 19:29:05.000000000 +0100
@@ -1027,7 +1027,7 @@
 #endif
 
 	if (opts.noaction)
-		flags |= MS_RDONLY;
+		flags |= NTFS_MNT_RDONLY;
 
 	//ntfs_log_set_levels (NTFS_LOG_LEVEL_DEBUG | NTFS_LOG_LEVEL_TRACE);
 	//ntfs_log_set_levels (NTFS_LOG_LEVEL_DEBUG);
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfstruncate.c ntfsprogs-1.13.1/ntfsprogs/ntfstruncate.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfstruncate.c	2006-04-05 04:45:56.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfstruncate.c	2006-11-28 19:29:05.000000000 +0100
@@ -738,7 +738,7 @@
 	/* Mount the device. */
 	if (opts.no_action) {
 		ntfs_log_quiet("Running in READ-ONLY mode!\n");
-		ul = MS_RDONLY;
+		ul = NTFS_MNT_RDONLY;
 	} else
 		ul = 0;
 	vol = ntfs_mount(dev_name, ul);
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfsundelete.c ntfsprogs-1.13.1/ntfsprogs/ntfsundelete.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfsundelete.c	2006-04-05 14:43:08.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfsundelete.c	2006-11-28 19:29:05.000000000 +0100
@@ -2123,7 +2123,7 @@
 
 	utils_set_locale();
 
-	vol = utils_mount_volume(opts.device, MS_RDONLY, opts.force);
+	vol = utils_mount_volume(opts.device, NTFS_MNT_RDONLY, opts.force);
 	if (!vol)
 		return 1;
 
diff -urN ntfsprogs-1.13.1-orig/ntfsprogs/ntfswipe.c ntfsprogs-1.13.1/ntfsprogs/ntfswipe.c
--- ntfsprogs-1.13.1-orig/ntfsprogs/ntfswipe.c	2006-04-05 14:43:08.000000000 +0200
+++ ntfsprogs-1.13.1/ntfsprogs/ntfswipe.c	2006-11-28 19:29:05.000000000 +0100
@@ -1340,7 +1340,7 @@
 		print_summary();
 
 	if (opts.info || opts.noaction)
-		flags = MS_RDONLY;
+		flags = NTFS_MNT_RDONLY;
 
 	vol = utils_mount_volume(opts.device, flags, opts.force);
 	if (!vol)

[ntfsprogs-1.13.1-vistahotfix.diff (text/plain, inline)]

Index: include/ntfs/volume.h
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/include/ntfs/volume.h,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- include/ntfs/volume.h	25 Nov 2006 17:37:37 -0000	1.26
+++ include/ntfs/volume.h	28 Nov 2006 10:09:57 -0000	1.27
@@ -54,6 +54,11 @@
 	NTFS_MNT_RDONLY	 	= 1,
 	NTFS_MNT_NOATIME 	= 2,
 	NTFS_MNT_CASE_SENSITIVE	= 4,
+ 	NTFS_MNT_NOT_EXCLUSIVE	= 8,
+	NTFS_MNT_FORENSIC	= 16, /* Mount for forensic purposes, i.e. do
+					 not do any writing at all during the
+					 mount, i.e. no journal emptying, no
+					 dirty bit setting, etc. */
 };
 
 /**
@@ -79,6 +83,10 @@
 	NV_CaseSensitive,	/* 1: Volume is mounted case-sensitive. */
 	NV_LogFileEmpty,	/* 1: $logFile journal is empty. */
 	NV_NoATime,		/* 1: Do not update access time. */
+	NV_WasDirty,		/* 1: Volume was marked dirty before we mounted
+				      it. */
+	NV_ForensicMount,	/* 1: Mount is forensic, i.e. no modifications
+				      are to be done by mount/umount. */
 } ntfs_volume_state_bits;
 
 #define  test_nvol_flag(nv, flag)	 test_bit(NV_##flag, (nv)->state)
@@ -101,6 +109,14 @@
 #define NVolSetNoATime(nv)		  set_nvol_flag(nv, NoATime)
 #define NVolClearNoATime(nv)		clear_nvol_flag(nv, NoATime)
 
+#define NVolWasDirty(nv)		 test_nvol_flag(nv, WasDirty)
+#define NVolSetWasDirty(nv)		  set_nvol_flag(nv, WasDirty)
+#define NVolClearWasDirty(nv)		clear_nvol_flag(nv, WasDirty)
+
+#define NVolForensicMount(nv)		 test_nvol_flag(nv, ForensicMount)
+#define NVolSetForensicMount(nv)	  set_nvol_flag(nv, ForensicMount)
+#define NVolClearForensicMount(nv)	clear_nvol_flag(nv, ForensicMount)
+
 /*
  * NTFS version 1.1 and 1.2 are used by Windows NT4.
  * NTFS version 2.x is used by Windows 2000 Beta
Index: libntfs/volume.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/libntfs/volume.c,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- libntfs/volume.c	25 Nov 2006 21:35:39 -0000	1.81
+++ libntfs/volume.c	28 Nov 2006 10:09:57 -0000	1.82
@@ -88,6 +88,14 @@
  */
 static void __ntfs_volume_release(ntfs_volume *v)
 {
+	/*
+	 * Clear the dirty bit if it was not set before we mounted and this is
+	 * not a forensic mount.
+	 */
+	if (!NVolReadOnly(v) && !NVolWasDirty(v) && !NVolForensicMount(v)) {
+		v->flags &= ~VOLUME_IS_DIRTY;
+		(void)ntfs_volume_write_flags(v, v->flags);
+	}
 	if (v->lcnbmp_ni && NInoDirty(v->lcnbmp_ni))
 		ntfs_inode_sync(v->lcnbmp_ni);
 	if (v->vol_ni)
@@ -780,7 +788,9 @@
 		ntfs_log_perror("Failed to startup volume");
 		return NULL;
 	}
-
+	/* Record whether this is a forensic mount. */
+	if (flags & NTFS_MNT_FORENSIC)
+		NVolSetForensicMount(vol);
 	/* Load data from $MFT and $MFTMirr and compare the contents. */
 	m = (u8*)malloc(vol->mftmirr_size << vol->mft_record_size_bits);
 	m2 = (u8*)malloc(vol->mftmirr_size << vol->mft_record_size_bits);
@@ -997,9 +1007,14 @@
 	/* Setup vol from the volume information attribute value. */
 	vol->major_ver = vinf->major_ver;
 	vol->minor_ver = vinf->minor_ver;
-	/* Do not use le16_to_cpu() macro here as our VOLUME_FLAGS are
-	   defined using cpu_to_le16() macro and hence are consistent. */
+	/*
+	 * Do not use le16_to_cpu() macro here as our VOLUME_FLAGS are defined
+	 * using cpu_to_le16() macro and hence are consistent.
+	 */
 	vol->flags = vinf->flags;
+	/* Record whether the volume was dirty or not. */
+	if (vol->flags & VOLUME_IS_DIRTY)
+		NVolSetWasDirty(vol);
 	/*
 	 * Reinitialize the search context for the $Volume/$VOLUME_NAME lookup.
 	 */
@@ -1115,12 +1130,26 @@
 	/*
 	 * Check for dirty logfile and hibernated Windows.
 	 * We care only about read-write mounts.
+	 *
+	 * If all is ok, reset the logfile and set the dirty bit on the volume.
+	 *
+	 * But do not do that if this is a FORENSIC mount.
 	 */
 	if (!(flags & NTFS_MNT_RDONLY)) {
 		if (ntfs_volume_check_logfile(vol) < 0)
 			goto error_exit;
 		if (ntfs_volume_check_hiberfile(vol) < 0)
 			goto error_exit;
+		if (!NVolForensicMount(vol)) {
+			if (ntfs_logfile_reset(vol) < 0)
+				goto error_exit;
+			if (!NVolWasDirty(vol)) {
+				vol->flags |= VOLUME_IS_DIRTY;
+				if (ntfs_volume_write_flags(vol, vol->flags) <
+						0)
+					goto error_exit;
+			}
+		}
 	}
 
 	return vol;
Index: ntfsprogs/ntfsclone.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsclone.c,v
retrieving revision 1.94
retrieving revision 1.95
diff -u -r1.94 -r1.95
--- ntfsprogs/ntfsclone.c	12 Nov 2006 22:46:50 -0000	1.94
+++ ntfsprogs/ntfsclone.c	28 Nov 2006 10:09:57 -0000	1.95
@@ -1328,7 +1328,7 @@
 		exit(1);
 	}
 
-	if (vol->flags & VOLUME_IS_DIRTY)
+	if (NVolWasDirty(vol))
 		if (opt.force-- <= 0)
 			err_exit(dirty_volume_msg, opt.volume);
 
Index: ntfsprogs/ntfscp.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfscp.c,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- ntfsprogs/ntfscp.c	12 Nov 2006 22:46:50 -0000	1.39
+++ ntfsprogs/ntfscp.c	28 Nov 2006 10:09:57 -0000	1.40
@@ -320,7 +320,7 @@
 		return 1;
 	}
 
-	if ((vol->flags & VOLUME_IS_DIRTY) && (!opts.force))
+	if (NVolWasDirty(vol) && !opts.force)
 		goto umount;
 
 	{
Index: ntfsprogs/ntfsdump_logfile.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsdump_logfile.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ntfsprogs/ntfsdump_logfile.c	12 Nov 2006 22:46:50 -0000	1.35
+++ ntfsprogs/ntfsdump_logfile.c	28 Nov 2006 10:09:57 -0000	1.36
@@ -197,7 +197,7 @@
 		ntfs_inode *ni;
 		ntfs_attr *na;
 
-		vol = ntfs_mount(filename, NTFS_MNT_RDONLY);
+		vol = ntfs_mount(filename, NTFS_MNT_RDONLY | NTFS_MNT_FORENSIC);
 		if (!vol)
 			log_err_exit(NULL, "Failed to mount %s: %s\n",
 					filename, strerror(errno));
Index: ntfsprogs/ntfsfix.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsfix.c,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- ntfsprogs/ntfsfix.c	5 Apr 2006 12:43:07 -0000	1.33
+++ ntfsprogs/ntfsfix.c	28 Nov 2006 10:09:57 -0000	1.34
@@ -82,8 +82,6 @@
 static const char *EXEC_NAME = "ntfsfix";
 static const char *OK        = "OK\n";
 static const char *FAILED    = "FAILED\n";
-static BOOL vol_is_dirty     = FALSE;
-static BOOL journal_is_empty = FALSE;
 
 struct {
 	char *volume;
@@ -247,9 +245,8 @@
 {
 	u16 flags;
 
-	if (vol_is_dirty == TRUE)
+	if (NVolWasDirty(vol))
 		return 0;
-
 	ntfs_log_info("Setting required flags on partition... ");
 	/*
 	 * Set chkdsk flag, i.e. mark the partition dirty so chkdsk will run
@@ -264,37 +261,9 @@
 		ntfs_log_error("Error setting volume flags.\n");
 		return -1;
 	}
+	vol->flags = flags;
 	ntfs_log_info(OK);
-	vol_is_dirty = TRUE;
-	return 0;
-}
-
-/**
- * set_dirty_flag_mount
- */
-static int set_dirty_flag_mount(ntfs_volume *vol)
-{
-	u16 flags;
-
-	if (vol_is_dirty == TRUE)
-		return 0;
-
-	ntfs_log_info("Setting required flags on partition... ");
-	/*
-	 * Set chkdsk flag, i.e. mark the partition dirty so chkdsk will run
-	 * and fix it for us.
-	 */
-	flags = vol->flags | VOLUME_IS_DIRTY;
-	/* If NTFS volume version >= 2.0 then set mounted on NT4 flag. */
-	if (vol->major_ver >= 2)
-		flags |= VOLUME_MOUNTED_ON_NT4;
-	if (ntfs_volume_write_flags(vol, flags)) {
-		ntfs_log_info(FAILED);
-		ntfs_log_error("Error setting volume flags.\n");
-		return -1;
-	}
-	ntfs_log_info(OK);
-	vol_is_dirty = TRUE;
+	NVolSetWasDirty(vol);
 	return 0;
 }
 
@@ -303,9 +272,8 @@
  */
 static int empty_journal(ntfs_volume *vol)
 {
-	if (journal_is_empty == TRUE)
+	if (NVolLogFileEmpty(vol))
 		return 0;
-
 	ntfs_log_info("Going to empty the journal ($LogFile)... ");
 	if (ntfs_logfile_reset(vol)) {
 		ntfs_log_info(FAILED);
@@ -313,7 +281,6 @@
 		return -1;
 	}
 	ntfs_log_info(OK);
-	journal_is_empty = TRUE;
 	return 0;
 }
 
@@ -475,13 +442,13 @@
 
 	ntfs_log_info("Attempting to correct errors... ");
 
-	dev = ntfs_device_alloc(opt.volume, 0, &ntfs_device_default_io_ops, NULL);
+	dev = ntfs_device_alloc(opt.volume, 0, &ntfs_device_default_io_ops,
+			NULL);
 	if (!dev) {
 		ntfs_log_info(FAILED);
 		ntfs_log_perror("Failed to allocate device");
 		return -1;
 	}
-
 	vol = ntfs_volume_startup(dev, 0);
 	if (!vol) {
 		ntfs_log_info(FAILED);
@@ -490,17 +457,12 @@
 		ntfs_device_free(dev);
 		return -1;
 	}
-
 	if (fix_mftmirr(vol) < 0)
 		goto error_exit;
-
-	/* FIXME: Will this fail?  Probably... */
 	if (set_dirty_flag(vol) < 0)
 		goto error_exit;
-
 	if (empty_journal(vol) < 0)
 		goto error_exit;
-
 	ret = 0;
 error_exit:
 	/* ntfs_umount() will invoke ntfs_device_free() for us. */
@@ -550,7 +512,8 @@
 			exit(1);
 		}
 	}
-
+	/* So the unmount does not clear it again. */
+	NVolSetWasDirty(vol);
 	/* Check NTFS version is ok for us (in $Volume) */
 	ntfs_log_info("NTFS volume version is %i.%i.\n", vol->major_ver,
 			vol->minor_ver);
@@ -558,22 +521,13 @@
 		ntfs_log_error("Error: Unknown NTFS version.\n");
 		goto error_exit;
 	}
-
-	if (set_dirty_flag_mount(vol) < 0)
-		goto error_exit;
-
-	if (empty_journal(vol) < 0)
-		goto error_exit;
-
 	if (vol->major_ver >= 3) {
-	/* FIXME: If on NTFS 3.0+, check for presence of the usn journal and
-	   disable it (if present) as Win2k might be unhappy otherwise and Bad
-	   Things(TM) could happen depending on what applications are actually
-	   using it for. */
+		/*
+		 * FIXME: If on NTFS 3.0+, check for presence of the usn
+		 * journal and stamp it if present.
+		 */
 	}
-
-	/* FIXME: Should we be marking the quota out of date, too? */
-
+	/* FIXME: We should be marking the quota out of date, too. */
 	/* That's all for now! */
 	ntfs_log_info("NTFS partition %s was processed successfully.\n",
 			vol->dev->d_name);
Index: ntfsprogs/ntfsinfo.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsinfo.c,v
retrieving revision 1.154
retrieving revision 1.155
diff -u -r1.154 -r1.155
--- ntfsprogs/ntfsinfo.c	25 Nov 2006 18:38:47 -0000	1.154
+++ ntfsprogs/ntfsinfo.c	28 Nov 2006 10:09:57 -0000	1.155
@@ -1165,7 +1165,7 @@
 			runlist *rlc = rl;
 			printf("\tRunlist:\tVCN\t\tLCN\t\tLength\n");
 			while (rlc->length) {
-				printf("\t\t\t%lld\t\t%lld\t\t%lld\n",
+				printf("\t\t\t0x%llx\t\t0x%llx\t\t0x%llx\n",
 					rlc->vcn, rlc->lcn, rlc->length);
 				rlc++;
 			}
Index: ntfsprogs/ntfsmove.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsmove.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- ntfsprogs/ntfsmove.c	12 Nov 2006 22:46:50 -0000	1.24
+++ ntfsprogs/ntfsmove.c	28 Nov 2006 10:09:57 -0000	1.25
@@ -889,10 +889,7 @@
 
 	count = move_file(vol, inode, opts.location, 0);
 	if ((count > 0) && (!opts.nodirty)) {
-		if (ntfs_volume_write_flags(vol, vol->flags | VOLUME_IS_DIRTY) <
-				0) {
-			ntfs_log_error("Couldn't mark volume dirty\n");
-		}
+		NVolSetWasDirty(vol);
 		ntfs_log_info("Relocated %lld bytes\n", count);
 	}
 	if (count >= 0)
Index: ntfsprogs/ntfsresize.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfsresize.c,v
retrieving revision 1.123
retrieving revision 1.124
diff -u -r1.123 -r1.124
--- ntfsprogs/ntfsresize.c	12 Nov 2006 22:46:50 -0000	1.123
+++ ntfsprogs/ntfsresize.c	28 Nov 2006 10:09:57 -0000	1.124
@@ -2256,7 +2256,7 @@
 		exit(1);
 	}
 
-	if (vol->flags & VOLUME_IS_DIRTY)
+	if (NVolWasDirty(vol))
 		if (opt.force-- <= 0)
 			err_exit("Volume is scheduled for check.\nRun chkdsk /f"
 				 " and please try again, or see option -f.\n");
@@ -2280,32 +2280,16 @@
 /**
  * prepare_volume_fixup
  *
- * Set the volume's dirty flag and wipe the filesystem journal.  When Windows
- * boots it will automatically run chkdsk to check for any problems.  If the
- * read-only command line option was given, this function will do nothing.
+ * Make sure the volume's dirty flag does not get cleared at umount time.  When
+ * Windows boots it will automatically run chkdsk to check for any problems.
+ * If the read-only command line option was given, this function will do
+ * nothing.
  */
 static void prepare_volume_fixup(ntfs_volume *vol)
 {
-	u16 flags;
-
-	flags = vol->flags | VOLUME_IS_DIRTY;
-	if (vol->major_ver >= 2)
-		flags |= VOLUME_MOUNTED_ON_NT4;
-
 	printf("Schedule chkdsk for NTFS consistency check at Windows "
 		"boot time ...\n");
-
-	if (ntfs_volume_write_flags(vol, flags))
-		perr_exit("Failed to set $Volume dirty");
-
-	if (vol->dev->d_ops->sync(vol->dev) == -1)
-		perr_exit("Failed to sync device");
-
-	printf("Resetting $LogFile ... (this might take a while)\n");
-
-	if (ntfs_logfile_reset(vol))
-		perr_exit("Failed to reset $LogFile");
-
+	NVolSetWasDirty(vol);
 	if (vol->dev->d_ops->sync(vol->dev) == -1)
 		perr_exit("Failed to sync device");
 }
Index: ntfsprogs/ntfswipe.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/ntfswipe.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- ntfsprogs/ntfswipe.c	12 Nov 2006 22:46:51 -0000	1.45
+++ ntfsprogs/ntfswipe.c	28 Nov 2006 10:09:57 -0000	1.46
@@ -1346,7 +1346,7 @@
 	if (!vol)
 		goto free;
 
-	if ((vol->flags & VOLUME_IS_DIRTY) && (!opts.force))
+	if (NVolWasDirty(vol) && !opts.force)
 		goto umount;
 
 	if (opts.info) {
Index: ntfsprogs/utils.c
===================================================================
RCS file: /cvs/linux-ntfs/ntfsprogs/ntfsprogs/utils.c,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -r1.69 -r1.70
--- ntfsprogs/utils.c	25 Nov 2006 21:44:36 -0000	1.69
+++ ntfsprogs/utils.c	28 Nov 2006 10:09:57 -0000	1.70
@@ -196,7 +196,7 @@
 		return NULL;
 	}
 
-	if (vol->flags & VOLUME_IS_DIRTY) {
+	if (NVolWasDirty(vol)) {
		ntfs_log_warning("Volume is dirty.\n");
		if (!force) {
			ntfs_log_error("Run chkdsk and try again, or use the "
					"force option.\n");

Message #468 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 21:27:48 +0000 (GMT)

On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> > On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> > relocate_inodes() -> relocate_inode() -> at the end of the function
> > calls write_mft_record() which uses the ntfs_volume and the libntfs
> > function ntfs_mft_record_write() to do the writing.
> 
> Think about relocating $MFT.

I don't understand what you mean.  If you relocate the mft itself and you 
do not update the ntfs_volume structure and the mft bitmap attribute inode 
which is kept open for the duration of the mount then with each call of 
ntfs_mft_record_write() in your relocate_inodes() it would write to the 
old locations instead of the new relocated locations...

> > After that we have truncate_badclust_file() and truncate_bitmap_file()
> > both of which use write_mft_record() also...
> 
> The beginning of the $MFT is never relocated, so the MFT records belonging
> to these files can be safely modified in place, otherwise resizing is
> restricted to a safe size.
> 
> > Remember that what you were doing was not working for Vista and it works
> > now...
> 
> 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:

Every time you run ntfsresize and either you answer "no" to the "really 
proceed" question or ntfsresize aborts without doing anything because it 
hits a "this is not supported" case or you try to resize to a too small 
size or anything like that the volume is left dirty thus running 
ntfsresize again then fails.  This is because ntfsresize does not unmount 
the volume.  My complete patches up to CVS head cause the unmounting to 
happen but only until all the checks have passed and ntfsresize is about 
to start migrating clusters around.  At that point, before the first 
modification happens, I turn off the unmounting and from then on 
ntfsresize will run and independent of when it is going to stop (abort or 
complete), it will no longer unmount like you want it to be.  Then the 
volume is left dirty which is what you want to happen anyway.

I think it is now correct.  Please take the time to review the patches...

> You seem to mix here two different problems: the missing log file reset in
> libntfs and the unsafe umount you introduced by another patch to ntfsresize
> because you thought that it was missing by accident.

Not really, as you see above if you do not unmount at all you now end up 
marking the volume dirty unconditionally even if ntfsresize does not 
actually do anything at all.

> > Anyway, given ntfsresize is your code, if you want to insist on not
> > allowing unmounting, then can you please tell me the exact point in the
> > code at which unmounting becomes dangerous/wrong 
> 
> I must think about it. The design rule was being always consistent or
> trivially recoverable whenever we exit immediately without any cleanup.

The current code does that I believe.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #473 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 28 Nov 2006 23:20:28 +0000 (GMT)

Hi,

On Tue, 28 Nov 2006, Frans Pop wrote:
> On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
> > There are two NTFS during resizing. The original and the resized. When
> > the resizing is over then the latter is consistent and the old one is
> > irrelevant. ntfsresize doesn't work like the other utilities: mount,
> > modify, umount. It works like: mount and morph the original into a new
> > one.
> 
> I'm going to wait with further testing until you have sorted out this 
> difference of opinion.
> 
> I guess that in this context "being mounted" is something different than 
> the filesystem being mounted from a linux filesystem point of view?

Yes, it is a call to ntfs_mount() from libntfs which is the library 
provided by ntfsprogs which ntfsresize uses.

> Szakacsits' statements do make me wonder though what happens if you do 
> (try to) mount/unmount a resized NTFS partition after resizing it, maybe 
> using the available "force" options.

Works fine.

> It also makes me wonder what happens when linux is shut down. Does it get 
> unmounted then after all or is that not relevant as the partition is not 
> mounted from a linux point of view?

Not relevant.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #478 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 02:49:51 +0200 (MET DST)

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

Message #483 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 03:10:47 +0200 (MET DST)

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> 
> Thank you for persisting with this.  

Yes, thank you Frans and Andree for your help. We definitely found 
something.

> I have now looked at the code and you are right it does not do the same 
> thing.  This is because when Yura ported my $LogFile code from the kernel 
> for some unknown to me (or forgotten by me) reason he did not integrate 
> clearing the journal into the mount process.  He integrated the checking 
> but not the clearing.  This is a HUGE and VERY BAD bug in libntfs and 
> means that all ntfs utilities are _DANGEROUS_ to run and can cause 
> massive and very hard to detect data corruption.  )-:

If the journal is not clean then the mount is refused. This detection was 
added later, previously the journal cleaning was unconditional because we 
didn't know if it's clean or not.

So, I don't see a big problem here. The reliability of ntfsresize and 
ntfs-3g seems to confirm this. Nobody reported corruptions, in fact, people 
are finding bad hardwares (RAM, disk, cable) and softwares during usage and 
testing. Almost like ZFS :-)))

> No wonder Vista does not boot!!!  

I still wonder why it doesn't boot. As I explained in my previous email, 
ntfsresize resets the journal unless the empty journal detection fails.

> It is amazing it took so long to find this problem.  I cannot believe we 
> managed to get away with it for so long...

For me it seems it worked as it should have. If the journal is clean, 
then theoretically it's pointless to empty. If unclean then mount is 
unconditionally refused.

	Szaka

Message #488 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 07:44:47 +0000 (GMT)

Szaka wrote: "pointless to empty journal if clean"...

It is NOT pointless to empty.  I think you do not understand how 
journalling in Windows works (or I don't understand it... (-;).  My 
understanding is that regardless whether the journal is clean or not 
Windows can/will parse the journal (at least in some cases, depends on the 
exact state of the journal) and redo various things/undo others as parts 
of its journalling startup.  Normally this has no effect as it just writes 
the same data over the existing data (unless a weird crash occurred in 
which case it will repair the volume).  However when you have modified the 
volume underneath with another ntfs driver or with ntfsresize or whatever, 
then doing such redo/undo operations are fatal.  Well they can be fatal 
anyway.  I guess in most cases they will silently corrupt stuff that one 
will not know about or even just write over now random locations on disk.  
The problem is this is totally unpredictable.  The only way to make not 
emptying the journal safe is to do journalling and keep the journal 
uptodate.  But none of us know how to do that so we better empty it to 
make sure everything is ok...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #493 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 08:19:15 +0000 (GMT)

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> 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.

Nope, that was all written as a consequence to the changes to libntfs 
mounting/unmounting.  A lot of fixing of code was needed to work with the 
changes in the utilities.  )-:

(Well there are two tiny things that slipped in, one is an ntfscat 
modification and one is a ntfsinfo modification but the major bulk of 
changes was all due to the mount changes.)

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #498 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 10:18:00 +0200 (MET DST)

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> Szaka wrote: "pointless to empty journal if clean"...
> 
> It is NOT pointless to empty.  

It depends on how journaling works, on which we disagree. It's useless to 
explain the consequences if you're right because I'm obviously aware of it. 
You would have a good argument if you said that "sniff and observe Windows 
reading all journal clusters during boot even if it's clean which means 
quite probably that it also analyzes it".

Anyway, ntfsresize always unconditionally emptied the journal. So what did 
you do which made Vista booting? It's either incorrect journal checking on 
Vista or a side-effect of your changes.

	Szaka

Message #503 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 09:05:46 +0000 (GMT)

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > Szaka wrote: "pointless to empty journal if clean"...
> > It is NOT pointless to empty.  
> 
> It depends on how journaling works, on which we disagree. It's useless to 
> explain the consequences if you're right because I'm obviously aware of it. 
> You would have a good argument if you said that "sniff and observe Windows 
> reading all journal clusters during boot even if it's clean which means 
> quite probably that it also analyzes it".

I read the code and it does it.  I do not believe in sniffing as you put 
it.  That is useless as you never know what/why the software is doing 
something.  The code itself shows exactly what happens.  I prefer to stick 
with that.

> Anyway, ntfsresize always unconditionally emptied the journal. So what did 
> you do which made Vista booting? It's either incorrect journal checking on 
> Vista or a side-effect of your changes.

I did two things to libntfs:
	- make the journal be emptied at mount time and 
	- set the dirty bit at mount time.
Then at umount time:
	- clear the dirty bit again unless the volume was dirty when it 
was mounted.

I then did these things to ntfsresize:
	- remove the journal emptying from ntfsresize as it is done by 
libntfs now at mount time,
	- remove the setting dirty of volume as that is also done at mount 
time;
	- make ntfsresize unmount the volume if one aborts which will 
clear the dirty bit again if the volume was not dirty to start with; and 
finally,
	- disable the unmount in ntfsresize once it is going to start 
resizing ntfs as you said that unmounting at that point becomes dangerous.

This fixes ntfsresize on Vista for me.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #508 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 11:19:23 +0100 (MET)

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> I read the code and it does it.  I do not believe in sniffing as you put 
> it.  That is useless as you never know what/why the software is doing 
> something.  The code itself shows exactly what happens.  I prefer to stick 
> with that.

I prefer understanding the code, testing the understanding is correct, and
getting continuous user confirmations that both of the previous are indeed
right.
 
> > Anyway, ntfsresize always unconditionally emptied the journal. So what did 
> > you do which made Vista booting? It's either incorrect journal checking on 
> > Vista or a side-effect of your changes.
> 
> I did two things to libntfs:
> 	- make the journal be emptied at mount time and 
> 	- set the dirty bit at mount time.
> Then at umount time:
> 	- clear the dirty bit again unless the volume was dirty when it 
> was mounted.
> 
> I then did these things to ntfsresize:
> 	- remove the journal emptying from ntfsresize as it is done by 
> libntfs now at mount time,
> 	- remove the setting dirty of volume as that is also done at mount 
> time;

In other words, they were moved to libntfs. No real change here.

> 	- make ntfsresize unmount the volume if one aborts which will 
> clear the dirty bit again if the volume was not dirty to start with; and 
> finally,
> 	- disable the unmount in ntfsresize once it is going to start 
> resizing ntfs as you said that unmounting at that point becomes dangerous.

This also has no effect during a successful resize process.

> This fixes ntfsresize on Vista for me.

You didn't answer how the journal looks after running ntfsresize without
your changes. That is, the non-empty journal file detection indeed works on
Vista.

I'd like to emphasize that your change is very dangerous. You did something
which is not understood at all. Perhaps Vista can boot now in your case, but
it's also possible that it will cause serious problems in other scenarios.

	Szaka

Message #513 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 14:21:06 +0000 (GMT)

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > This fixes ntfsresize on Vista for me.
> 
> You didn't answer how the journal looks after running ntfsresize without
> your changes. That is, the non-empty journal file detection indeed works on
> Vista.

I have not the faintest idea what was wrong before.  All I noticed was 
that libntfs was not resetting the journal and was not marking volumes 
dirty.  This is what ntfsfix was doing.  So I moved it to libntfs 
ntfs_mount as it belongs there and then dealt with all the fall out from 
that...  I then tried running ntfsresize and to my surprise it now made 
Vista work.  Why - no idea, and I could not care less.  It works now.

> I'd like to emphasize that your change is very dangerous. You did something
> which is not understood at all. Perhaps Vista can boot now in your case, but
> it's also possible that it will cause serious problems in other scenarios.

It will not.  At least my changes to ntfsresize are perfectly well 
undersstood:  As you said I moved the functionality to libntfs, that's 
all.  Why it works as a consequence I have no idea.  I assumed I would 
have to do more work on ntfsresize afterwards but for some bizzare reason 
that was enough.  So ntfsresize was not doing something or doing something 
wrong and now that libntfs is doing the job it just works.  If you want to 
know why you are welcome to spend your own time figuring that out.  I am 
afraid I have too much work to do to care...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #518 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 18:11:58 +0100 (MET)

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> I have not the faintest idea what was wrong before. [...] to my surprise
> it now made Vista work.  Why - no idea, and I could not care less.

So, you have no idea of

	- what was wrong before
	- why ntfsresize works on your Vista now
	- internal knowledge of ntfsresize
	- what are the impacts of your change

but you would still make a new "stable" release. For me, these aren't very
solid and convincing technically at all.

My plan was to make an urgent release which would have included only the
denial of the Vista NTFS resizing, based on what I've suggested earlier.
Then there would have been enough time to investigate what's going on when
Vista becomes publicly available.

But this is your project, and of course you can do whatever you want.
Recently you messed up ntfsclone and now ntfsresize. Nothing I could do
about these, unfortunately. The responsibility is yours from now because
obviously I can't support code I disagree with and even you don't understand
why it works.

	Szaka

Message #523 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 18:29:41 +0000 (GMT)

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > I have not the faintest idea what was wrong before. [...] to my surprise
> > it now made Vista work.  Why - no idea, and I could not care less.
> 
> So, you have no idea of
> 
> 	- what was wrong before

Yes.

> 	- why ntfsresize works on your Vista now

Yes.

> 	- internal knowledge of ntfsresize

I have quite a bit now that I have looked at it.

> 	- what are the impacts of your change

I understand the impact 100% which is why my patch is so big.  It had to 
touch a lot of utilities to adapt for the changed libntfs behaviour.

> but you would still make a new "stable" release. For me, these aren't very
> solid and convincing technically at all.

It works.  As soon as Frans or others have confirmed that ntfsresize now 
works for them also that is quite good enough for me.

> My plan was to make an urgent release which would have included only the
> denial of the Vista NTFS resizing, based on what I've suggested earlier.
> Then there would have been enough time to investigate what's going on when
> Vista becomes publicly available.

How would you tell if it is a Vista partition or not?  How do you know 
that the partition you are resizing is not going to be attached to a Vista 
machine next?  Impossible to know if you ask me.

> But this is your project, and of course you can do whatever you want.
> Recently you messed up ntfsclone and now ntfsresize. Nothing I could do
> about these, unfortunately. The responsibility is yours from now because
> obviously I can't support code I disagree with and even you don't understand
> why it works.

This is ridiculous.  Grow up.  I have neither messed up ntfsclone nor 
ntfsresize.  You just can't cope with the idea that someone touches code 
you have written...

Both work perfectly after my changes and better than they did before.  
Just because you perhaps cannot understand the fixes/improvements does not 
mean they are messed up.  Show me examples of what my changes have broken 
that was not broken to start with and I will take my words back and 
personally remove my patches.

Anyway, be my guest.  Revert my fixes and fix them in a different/better 
way.  I could not care less.  As long as the bugs are gone.  But please do 
not touch any of the libntfs/utilities other than ntfsresize/ntfsclone in 
the process, i.e. please work within the framework of the improved/fixed 
libntfs.  If you want the old behaviour of libntfs back then supply 
NTFS_MNT_FORENSIC to ntfs_mount() and libntfs will not write anything to 
the volume during the mount process, i.e. it will not clear the journal 
and it will not set the volume dirty.  Then if you alse revert my changes 
to ntfsresize you have your old broken ntfsresize back.  Now lets see you 
fix it if you know so much better, o wise one!

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #528 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 20:34:28 +0100 (MET)

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> 
> I understand the impact 100% which is why my patch is so big.  It had to 
> touch a lot of utilities to adapt for the changed libntfs behaviour.

The impact to resizing any kind of NTFS. There are many special cases and
ntfsresize works quite differently as you believe. It has its own attribute
resizer, cluster allocator, modifies mft records and not inodes, has strict
ordering of the modifications, etc.

You don't know what you fixed and how fixed. Still you think it doesn't have
any side-effects anywhere because it seems it workes a few times. And you
simply ignore all the cases which did work beforehand.

> How would you tell if it is a Vista partition or not?  

Detect Vista specific files which are always present.

> How do you know that the partition you are resizing is not going to be
> attached to a Vista machine next?  

I think it would work fine. The problem is with Vista volumes, not random
volumes attached to Vista.

> You just can't cope with the idea that someone touches code you have
> written...

I asked very simple technical questions from you:

   - How the journal looks on Vista after resizing without your patch?

   - What did you fix?

The first would have taken about 1-2 minutes from you. I even showed how 
you can do this. You keep it ignoring. Only you have Vista, unfortunately 
I don't. You also don't know what in fact you have fixed.

I'm only interested in the technical explanation but that's not coming.  
Only "works for me" which I can't consider responsible software engineering,
especially considering that how many people are using the software. Sorry.

Regards,
		Szaka

Message #533 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Thu, 30 Nov 2006 21:12:23 +0000 (GMT)

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> I think it would work fine. The problem is with Vista volumes, not random
> volumes attached to Vista.

You know that do you?  Given you don't have Vista that is just an 
assumption...

> I asked very simple technical questions from you:
> 
>    - How the journal looks on Vista after resizing without your patch?
> 
>    - What did you fix?
> 
> The first would have taken about 1-2 minutes from you. I even showed how 
> you can do this. You keep it ignoring. Only you have Vista, unfortunately 
> I don't. You also don't know what in fact you have fixed.

I told you I don't have the time to do the former!  1-2 minutes.  Ha!  At 
that time of day more like 2 hours sitting in the car + at least 15-30 
minutes figuring out how to drive cvs to revert my code changes and doing 
it + 5 minutes to compile it + 15 minutes or so to boot vmware/vista, 
format the data partition with vista, +5 minutes ti shutdown vista/vmware 
and flush buffers, the a minute to run ntfsresize, then 5 minutes to look 
at journal.  So about 3 hours later I would have been able to give you an 
answer.  If I had 3 spare hours I would play with my children or spend an 
extra evening with my wife and not waste them on satisfying your 
curiosity, sorry.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #538 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 2 Dec 2006 00:44:55 +0200 (MET DST)

Hi,

Apparently Vista refuses to boot if an NTFS volume was mounted on 
NT4 earlier. This is also what ntfsresize lied to trick Windows 
to be compatible with "itself". 

Could you please try the below patch against ntfsprogs 1.13.1 that the 
theory is correct? Thank you.

	Szaka

--- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.000000000 +0200
+++ ntfsprogs/ntfsresize.c      2006-12-02 00:09:44.058395088 +0200
@@ -2289,8 +2289,6 @@
        u16 flags;

        flags = vol->flags | VOLUME_IS_DIRTY;
-       if (vol->major_ver >= 2)
-               flags |= VOLUME_MOUNTED_ON_NT4;

        printf("Schedule chkdsk for NTFS consistency check at Windows "
                "boot time ...\n");

Message #543 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Andree Leidenfrost <andree@debian.org>, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 2 Dec 2006 15:36:27 +0200 (MET DST)

On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:

> Apparently Vista refuses to boot if an NTFS volume was mounted on 
> NT4 earlier. This is also what ntfsresize lied to trick Windows 
> to be compatible with "itself". 
> 
> Could you please try the below patch against ntfsprogs 1.13.1 that the 
> theory is correct? Thank you.

I put a statically linked version here to ease the testing.

	http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz

Thanks,
	Szaka

> --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.000000000 +0200
> +++ ntfsprogs/ntfsresize.c      2006-12-02 00:09:44.058395088 +0200
> @@ -2289,8 +2289,6 @@
>         u16 flags;
> 
>         flags = vol->flags | VOLUME_IS_DIRTY;
> -       if (vol->major_ver >= 2)
> -               flags |= VOLUME_MOUNTED_ON_NT4;
> 
>         printf("Schedule chkdsk for NTFS consistency check at Windows "
>                 "boot time ...\n");
> 

Message #548 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 02 Dec 2006 20:44:41 +0100

[Message part 1 (text/plain, inline)]

On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
> On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:
> > Apparently Vista refuses to boot if an NTFS volume was mounted on
> > NT4 earlier. This is also what ntfsresize lied to trick Windows
> > to be compatible with "itself".
>
> I put a statically linked version here to ease the testing.
> 	http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz

This version makes Vista happy too. After reboot chkdsk is executed and on 
second reboot Vista boots successfully.

There is a subtle difference: with Anton's fix the progress indicator 
Vista shows during the initial stage of the boot runs much faster than 
with this fix; unsure if that is significant though.

Cheers,
FJP

P.S. Szakacsits and Anton:
As you both know I've invested a _huge_ amount of time in tracing this 
issue and providing the information needed. The first reaction was 
basically "this can't be our bug" and now that it turns out it is, things 
run the risk of getting stuck in a kind of turf war between developers.

I do appreciate all the help you both have provided, but I'd also really 
appreciate if you'd make the effort to settle your differences and 
release a fixed version.
There is still time to get it out into the world before Vista becomes 
common and even to get it into Debian Etch, but only if you can settle on 
the correct patch quickly.

[Message part 2 (application/pgp-signature, inline)]

Message #553 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 2 Dec 2006 23:39:56 +0100

[Message part 1 (text/plain, inline)]

El sábado, 2 de diciembre de 2006 20:44, Frans Pop escribió:
[...]
> P.S. Szakacsits and Anton:
> As you both know I've invested a _huge_ amount of time in tracing this
> issue and providing the information needed. The first reaction was
> basically "this can't be our bug" and now that it turns out it is, things
> run the risk of getting stuck in a kind of turf war between developers.
>
> I do appreciate all the help you both have provided, but I'd also really
> appreciate if you'd make the effort to settle your differences and
> release a fixed version.

	I cannot agree more with Frans.  I think that we ceased to understand your 
technical talk several mails ago, so you are the only people qualified to fix 
this issue.

> There is still time to get it out into the world before Vista becomes
> common and even to get it into Debian Etch, but only if you can settle on
> the correct patch quickly.

	I am listening since a week ago, to see if a final patch arises and then make 
a prompt release.

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #558 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: David Martínez Moreno <ender@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 04:22:03 +0200 (MET DST)

> El sábado, 2 de diciembre de 2006 20:44, Frans Pop escribió:
> > On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
> > >
> > > I put a statically linked version here to ease the testing.
> > >      http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> >
> > This version makes Vista happy too. After reboot chkdsk is executed and 
> > on second reboot Vista boots successfully.

Thanks. So we know now the technical reason why ntfsresize didn't work 
previously. Vista deliberately refuses to mount NTFS if it thinks it was 
mounted by NT4. Though this wasn't very clear from the halt message :-)

> > There is a subtle difference: with Anton's fix the progress indicator
> > Vista shows during the initial stage of the boot runs much faster than
> > with this fix; unsure if that is significant though.

This is pure luck, random or user entertainment. The on-disk NTFS 
filesystems are exactly the same in both cases, just the codes are 
different a bit (I noted an important difference in an earlier email: 
no modification is made to the volume in my version unless it found 
to be consistent and all sanity checks pass).

> > P.S. Szakacsits and Anton:
> > As you both know I've invested a _huge_ amount of time in tracing this
> > issue and providing the information needed. 

I couldn't have figured out the reason without your images. Thanks!

> > The first reaction was basically "this can't be our bug" and now that 
> > it turns out it is, 

Well, things worked as expected. We say we are NT4 to chkdsk and Vista 
behaves according to the current Microsoft NT4 product support policy, that 
is, it doesn't boot.

> > things run the risk of getting stuck in a kind of turf war between 
> > developers.

There isn't any war here :-) Nobody knew what the problem was until you 
confirmed the NT4 related suspicion now. 

Anton was happy with the not understood fix which in fact was a bug in his 
patch which made Vista to boot by pure luck. To be honest, I've been 
working on ntfsresize alone for almost five years, and I very well know how 
many things could go wrong easily if no special attention is taken. I've 
never released a version which wasn't fully understood and very well 
tested. So I'm strongly against any not understood fixes (which actually 
indeed turned out to be a bug during Anton's changes).

The current Vista fixes (either one) could mean that maybe all non-Vista 
(XP, W2K, W2K3) stop booting now or corrupt NTFS. I don't think so but I've 
never tried and investigated it either. 

Probably the safest way is doing what we did previously and use the fix 
only with Vista. Ntfs-3g works fine with Vista, so since we can boot now 
thus I don't think there would be any other unexpected problem.

> > I do appreciate all the help you both have provided, but I'd also really
> > appreciate if you'd make the effort to settle your differences and
> > release a fixed version.

Anton makes the choice for ntfsprogs. I've left the linux-ntfs project a 
few days ago, and continue working only on ntfs-3g till there is interest.

But I'll make a fix for ntfsprogs-1.13.1, as soon as my time allows 
(probably not more than a few days). It might be even part of ntfs-3g in 
the future (online, offline resizing, defrag, etc). But these would be very 
low priorities till the full write support is finished (only a couple of 
decades left, if I counted it correctly).

Regards,
		Szaka

Message #563 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 03 Dec 2006 16:27:55 +1100

[Message part 1 (text/plain, inline)]

Hi Szaka,

Thanks a lot for the static binary!

I've tested and all looks well! When booting into Vista after a resize,
chkdsk is started and after another reboot the system starts as usual.
You are a star!!!!

Cheers,
Andree

On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote:
> On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:
> 
> > Apparently Vista refuses to boot if an NTFS volume was mounted on 
> > NT4 earlier. This is also what ntfsresize lied to trick Windows 
> > to be compatible with "itself". 
> > 
> > Could you please try the below patch against ntfsprogs 1.13.1 that the 
> > theory is correct? Thank you.
> 
> I put a statically linked version here to ease the testing.
> 
> 	http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> 
> Thanks,
> 	Szaka
> 
> > --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.000000000 +0200
> > +++ ntfsprogs/ntfsresize.c      2006-12-02 00:09:44.058395088 +0200
> > @@ -2289,8 +2289,6 @@
> >         u16 flags;
> > 
> >         flags = vol->flags | VOLUME_IS_DIRTY;
> > -       if (vol->major_ver >= 2)
> > -               flags |= VOLUME_MOUNTED_ON_NT4;
> > 
> >         printf("Schedule chkdsk for NTFS consistency check at Windows "
> >                 "boot time ...\n");
> > 
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #568 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: David Martínez Moreno <ender@debian.org>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 08:39:03 +0000 (GMT)

[Message part 1 (text/plain, inline)]

On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
> > El sábado, 2 de diciembre de 2006 20:44, Frans Pop escribió:
> > > On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
> > > >
> > > > I put a statically linked version here to ease the testing.
> > > >      http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> > >
> > > This version makes Vista happy too. After reboot chkdsk is executed and 
> > > on second reboot Vista boots successfully.
> 
> Thanks. So we know now the technical reason why ntfsresize didn't work 
> previously. Vista deliberately refuses to mount NTFS if it thinks it was 
> mounted by NT4. Though this wasn't very clear from the halt message :-)

Yes there not being a halt message at all!  Nice to know, thanks for 
working it out!  It is very intersting that they no longer allow NT4 to 
access Vista NTFS volumes.  I still wonder whether this may be a Vista bug 
rather than intentional...

Interesting though, what happens when you present Vista with an NTFS 1.2 
version formatted volume?  Will it refuse to boot, too or will it simply 
upgrade it like 2k/XP did?  If it refuses to boot it is time to remove the 
mkntfs v1.2 support now so people can't by accident create old style 
volumes that will break Vista...

> Anton was happy with the not understood fix which in fact was a bug in his 
> patch which made Vista to boot by pure luck. To be honest, I've been 

I object to it being called a bug.  I very consicously removed the mounted 
by NT4 flag setting as linux-ntfs operates like NT5 not NT4 so it is silly 
to set the flag.  I have even been considering removing support for NT4 
volumes and upgrading them on mount like Win2k/XP do, perhaps with an 
option to disable (or enable) this behaviour...

The only place the NT4 flag has is to be set by ntfsfix on volumes after 
being written to with the old ntfs driver which hopefully is no longer in 
use so ntfsfix does not need to set that flag either any more...  Remember 
that this was what I wrote ntfsfix for in the first place: to make writing 
with the old driver at least a little bit less broken...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #573 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: David Martínez Moreno <ender@debian.org>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net, Frans Pop <elendil@planet.nl>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 09:04:39 +0000 (GMT)

[Message part 1 (text/plain, inline)]

The linux-ntfs CVS now contains an adapted ntfsresize that restores the 
old behiour where the volume is not modified until the user says "yes" to 
begin modifications.  That is a lot less work than changing the 
documentation + output messages of ntfsresize and it is "least surprise" 
for users who upgrade to new version.

The only difference to Szaka's version is that ntfsresize now only sets 
the dirty flag if the volume is not already dirty and it only empties the 
journal if it is not already empty.  It seems silly to do things that are 
already the case especially when they are things that can take a while 
like emptying the journal.

Best regards,

	Anton

On Sun, 3 Dec 2006, Anton Altaparmakov wrote:
> On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
> > > El sábado, 2 de diciembre de 2006 20:44, Frans Pop escribió:
> > > > On Saturday 02 December 2006 14:36, Szakacsits Szabolcs wrote:
> > > > >
> > > > > I put a statically linked version here to ease the testing.
> > > > >      http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> > > >
> > > > This version makes Vista happy too. After reboot chkdsk is executed and 
> > > > on second reboot Vista boots successfully.
> > 
> > Thanks. So we know now the technical reason why ntfsresize didn't work 
> > previously. Vista deliberately refuses to mount NTFS if it thinks it was 
> > mounted by NT4. Though this wasn't very clear from the halt message :-)
> 
> Yes there not being a halt message at all!  Nice to know, thanks for 
> working it out!  It is very intersting that they no longer allow NT4 to 
> access Vista NTFS volumes.  I still wonder whether this may be a Vista bug 
> rather than intentional...
> 
> Interesting though, what happens when you present Vista with an NTFS 1.2 
> version formatted volume?  Will it refuse to boot, too or will it simply 
> upgrade it like 2k/XP did?  If it refuses to boot it is time to remove the 
> mkntfs v1.2 support now so people can't by accident create old style 
> volumes that will break Vista...
> 
> > Anton was happy with the not understood fix which in fact was a bug in his 
> > patch which made Vista to boot by pure luck. To be honest, I've been 
> 
> I object to it being called a bug.  I very consicously removed the mounted 
> by NT4 flag setting as linux-ntfs operates like NT5 not NT4 so it is silly 
> to set the flag.  I have even been considering removing support for NT4 
> volumes and upgrading them on mount like Win2k/XP do, perhaps with an 
> option to disable (or enable) this behaviour...
> 
> The only place the NT4 flag has is to be set by ntfsfix on volumes after 
> being written to with the old ntfs driver which hopefully is no longer in 
> use so ntfsfix does not need to set that flag either any more...  Remember 
> that this was what I wrote ntfsfix for in the first place: to make writing 
> with the old driver at least a little bit less broken...
> 
> Best regards,
> 
> 	Anton
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #578 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 11:25:45 +0100

[Message part 1 (text/plain, inline)]

El domingo, 3 de diciembre de 2006 10:04, Anton Altaparmakov escribió:
> The linux-ntfs CVS now contains an adapted ntfsresize that restores the
> old behiour where the volume is not modified until the user says "yes" to
> begin modifications.  That is a lot less work than changing the
> documentation + output messages of ntfsresize and it is "least surprise"
> for users who upgrade to new version.
>
> The only difference to Szaka's version is that ntfsresize now only sets
> the dirty flag if the volume is not already dirty and it only empties the
> journal if it is not already empty.  It seems silly to do things that are
> already the case especially when they are things that can take a while
> like emptying the journal.

	Thank you very much, guys.  What should we do know, apply the two-line patch 
from Szaka to 1.13.1, wait for 1.14, backport any other change...?

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #583 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: David Martínez Moreno <ender@debian.org>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 10:36:01 +0000 (GMT)

[Message part 1 (text/plain, inline)]

On Sun, 3 Dec 2006, David Martínez Moreno wrote:
> El domingo, 3 de diciembre de 2006 10:04, Anton Altaparmakov escribió:
> > The linux-ntfs CVS now contains an adapted ntfsresize that restores the
> > old behiour where the volume is not modified until the user says "yes" to
> > begin modifications.  That is a lot less work than changing the
> > documentation + output messages of ntfsresize and it is "least surprise"
> > for users who upgrade to new version.
> >
> > The only difference to Szaka's version is that ntfsresize now only sets
> > the dirty flag if the volume is not already dirty and it only empties the
> > journal if it is not already empty.  It seems silly to do things that are
> > already the case especially when they are things that can take a while
> > like emptying the journal.
> 
> 	Thank you very much, guys.  What should we do know, apply the two-line patch 
> from Szaka to 1.13.1, wait for 1.14, backport any other change...?

Entirely up to you.  If you want it immediately it is easiest if you apply 
the two-line patch from Szaka now and make your release and then when the 
next ntfsprogs release is done (it will be 2.0 not 1.14 btw) then you can 
release that.

Sound good?

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #588 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 12:39:45 +0100

[Message part 1 (text/plain, inline)]

El domingo, 3 de diciembre de 2006 11:36, Anton Altaparmakov escribió:
> > 	Thank you very much, guys.  What should we do know, apply the two-line
> > patch from Szaka to 1.13.1, wait for 1.14, backport any other change...?
>
> Entirely up to you.  If you want it immediately it is easiest if you apply
> the two-line patch from Szaka now and make your release and then when the
> next ntfsprogs release is done (it will be 2.0 not 1.14 btw) then you can
> release that.
>
> Sound good?

	Like a charm. :-)

	As you probably know, we want to release Debian etch by the end of the year, 
and this bug was a showstopper.  I will release a patched 1.13.1 then (no big 
changes).

	Frans, I will try to upload by today or tomorrow a new package.

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #593 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: David Martínez Moreno <ender@debian.org>

Cc: Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 15:28:05 +0200 (MET DST)

On Sun, 3 Dec 2006, David [iso-8859-15] Martínez Moreno wrote:
> El domingo, 3 de diciembre de 2006 11:36, Anton Altaparmakov escribió:
> > > 	Thank you very much, guys.  What should we do know, apply the two-line
> > > patch from Szaka to 1.13.1, wait for 1.14, backport any other change...?
> >
> > Entirely up to you.  If you want it immediately it is easiest if you apply
> > the two-line patch from Szaka now and make your release and then when the
> > next ntfsprogs release is done (it will be 2.0 not 1.14 btw) then you can
> > release that.
> >
> > Sound good?
> 
> 	Like a charm. :-)

Sorry I didn't explain myself better. My patch was only for Vista. 

I'm paranoidly careful with changes and would like to know the exact 
side-effects on the bit level on the entire volume for all non-Vista 
Microsoft NTFS drivers (there are quite many!). But I don't have the 
resources for that (hardware, OS, time, etc). So I'll make a surely safe 
patch asap.

Of course anybody is welcome to do it earlier based on what I suggested 
previously. It's not difficult (detect Vista and don't use the 
VOLUME_MOUNTED_ON_NT4 flag).

Btw, there are other reliability problems with the current ntfsprogs, I'll 
write about them later.

> 	As you probably know, we want to release Debian etch by the end of 
> the year, and this bug was a showstopper.  I will release a patched 
> 1.13.1 then (no big changes).

This is an __EXTREMELY__ urgent issue. Each day costs probably at least 
hundreds of "trashed" Vista. People won't migrate immediately, it will take 
many years. Anytime somebody use their old, trusted ntfs resizing solution 
with vista (gparted, qtparted, diskdrake, partition logic, older Linux 
installers, etc, etc) they will be in trouble.

The same happened when the HDIO_GETGEO ioctl semantic has changed 4 years 
ago in the kernel and Parted (which is used by almost all partitioners) 
started to trash Windows partition tables which is still not fully fixed 
today.

Thankfully Vista includes a resizer and it's easy to understand this 
problem. But we also must make a well articulated solution for unbootable 
Vista and spread these info and warning as quickly as possible. 

	Szaka

Message #598 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Anton Altaparmakov <aia21@cam.ac.uk>

To: Szakacsits Szabolcs <szaka@sienet.hu>

Cc: David Martínez Moreno <ender@debian.org>, 379628@bugs.debian.org, linux-ntfs-dev@lists.sf.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 13:45:27 +0000 (GMT)

[Message part 1 (text/plain, inline)]

On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
> On Sun, 3 Dec 2006, David [iso-8859-15] Martínez Moreno wrote:
> > El domingo, 3 de diciembre de 2006 11:36, Anton Altaparmakov escribió:
> > > > 	Thank you very much, guys.  What should we do know, apply the two-line
> > > > patch from Szaka to 1.13.1, wait for 1.14, backport any other change...?
> > >
> > > Entirely up to you.  If you want it immediately it is easiest if you apply
> > > the two-line patch from Szaka now and make your release and then when the
> > > next ntfsprogs release is done (it will be 2.0 not 1.14 btw) then you can
> > > release that.
> > >
> > > Sound good?
> > 
> > 	Like a charm. :-)
> 
> Sorry I didn't explain myself better. My patch was only for Vista. 

Disagree.  Your patch is fine for all NTFS volumes.  There is no need to 
set the mounted on NT4 bit on any volume during what NTFS resize does.  It 
does not do anything that would be analogous to an NT4 operation.  I have 
no idea why you ever set the flag.  As far as I am concerned setting that 
flag at all is an outright bug in NTFS resize.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Message #603 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Anton Altaparmakov <aia21@cam.ac.uk>

Cc: David Martínez Moreno <ender@debian.org>, linux-ntfs-dev@lists.sf.net, 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 16:13:34 +0200 (MET DST)

On Sun, 3 Dec 2006, Anton Altaparmakov wrote:
> On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
> > 
> > Sorry I didn't explain myself better. My patch was only for Vista. 
> 
> Disagree.  Your patch is fine for all NTFS volumes.  There is no need to 
> set the mounted on NT4 bit on any volume during what NTFS resize does.  It 
> does not do anything that would be analogous to an NT4 operation.  I have 
> no idea why you ever set the flag.  As far as I am concerned setting that 
> flag at all is an outright bug in NTFS resize.

Ntfsresize works based on the volume version but unconditionally sets 
VOLUME_MOUNTED_ON_NT4 to make chkdsk believe and fix potentially missed 
V3.x modifications. 

I'm not aware of such problem but that doesn't mean there can't be any. 
So you may or may not be right but me being over paranoid about reliability 
I stick to the latter for now. Though an explicit and official guarantee 
from Microsoft could change my standpoint.

	Szaka

Message #608 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 18:42:55 +0200 (MET DST)

Hi Andree,

On Sun, 3 Dec 2006, Andree Leidenfrost wrote:

> I've tested and all looks well! When booting into Vista after a resize,
> chkdsk is started and after another reboot the system starts as usual.
> You are a star!!!!

Thanks for the testing but I object the last sentence because I think this 
was quite a team work ;-)

Cheers,
	Szaka

Message #613 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org

Cc: Anton Altaparmakov <aia21@cam.ac.uk>, linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 3 Dec 2006 18:17:52 +0100

[Message part 1 (text/plain, inline)]

El domingo, 3 de diciembre de 2006 15:13, Szakacsits Szabolcs escribió:
> On Sun, 3 Dec 2006, Anton Altaparmakov wrote:
> > On Sun, 3 Dec 2006, Szakacsits Szabolcs wrote:
> > > Sorry I didn't explain myself better. My patch was only for Vista.
> >
> > Disagree.  Your patch is fine for all NTFS volumes.  There is no need to
> > set the mounted on NT4 bit on any volume during what NTFS resize does. 
> > It does not do anything that would be analogous to an NT4 operation.  I
> > have no idea why you ever set the flag.  As far as I am concerned setting
> > that flag at all is an outright bug in NTFS resize.
>
> Ntfsresize works based on the volume version but unconditionally sets
> VOLUME_MOUNTED_ON_NT4 to make chkdsk believe and fix potentially missed
> V3.x modifications.
>
> I'm not aware of such problem but that doesn't mean there can't be any.
> So you may or may not be right but me being over paranoid about reliability
> I stick to the latter for now. Though an explicit and official guarantee
> from Microsoft could change my standpoint.

	I have some contacts at Microsoft.  If you can summarize this problem into a 
question, I could have some answers.  Not official, but some answers.

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #618 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>, David Martínez Moreno <ender@debian.org>, Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, Frans Pop <elendil@planet.nl>, linux-ntfs-dev@lists.sf.net, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 04 Dec 2006 08:06:32 +1100

[Message part 1 (text/plain, inline)]

Szaka, David, Frans,

Okidoki, what happens now? I'd be keen to see this in the package and
then in the installer ASAP.

Is there going to be a new upstream release? Is the patch just going to
be applied to the Debbian package? (Looks easy enough to me.)

If there is anything I can do to help, please let me know.

Cheers,
Andree

On Sun, 2006-12-03 at 18:42 +0200, Szakacsits Szabolcs wrote:
> Hi Andree,
> 
> On Sun, 3 Dec 2006, Andree Leidenfrost wrote:
> 
> > I've tested and all looks well! When booting into Vista after a resize,
> > chkdsk is started and after another reboot the system starts as usual.
> > You are a star!!!!
> 
> Thanks for the testing but I object the last sentence because I think this 
> was quite a team work ;-)
> 
> Cheers,
> 	Szaka
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #623 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: linux-ntfs-dev@lists.sf.net

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Mon, 04 Dec 2006 15:49:35 +0100

[Message part 1 (text/plain, inline)]

On Sunday 03 December 2006 22:06, Andree Leidenfrost wrote:
> Okidoki, what happens now? I'd be keen to see this in the package and
> then in the installer ASAP.

Note that this was not the only issue affecting resizing Vista partitions 
in the installer. There is also #380226 in parted. And I'm very sorry to 
say that it seems there has still been no action on that one by the 
maintainers of parted.

> Is there going to be a new upstream release? Is the patch just going to
> be applied to the Debbian package? (Looks easy enough to me.)

I think this has already been answered in earlier mails.

[Message part 2 (application/pgp-signature, inline)]

Message #628 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org, ender@debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Tue, 5 Dec 2006 00:06:45 +0100

[Message part 1 (text/plain, inline)]

El lunes, 4 de diciembre de 2006 15:49, Frans Pop escribió:
> On Sunday 03 December 2006 22:06, Andree Leidenfrost wrote:
> > Okidoki, what happens now? I'd be keen to see this in the package and
> > then in the installer ASAP.
>
> Note that this was not the only issue affecting resizing Vista partitions
> in the installer. There is also #380226 in parted. And I'm very sorry to
> say that it seems there has still been no action on that one by the
> maintainers of parted.
>
> > Is there going to be a new upstream release? Is the patch just going to
> > be applied to the Debbian package? (Looks easy enough to me.)
>
> I think this has already been answered in earlier mails.

	Frans, I think that, not having a better solution, I am going to apply the 
two-line patch to linux-ntfs and release a new version, is it fine for you?

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #633 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Wed, 06 Dec 2006 00:38:18 +0100

[Message part 1 (text/plain, inline)]

On Tuesday 05 December 2006 00:06, David Martínez Moreno wrote:
> 	Frans, I think that, not having a better solution, I am going to apply
> the two-line patch to linux-ntfs and release a new version, is it fine
> for you?

Yes, that would be fine with me.
However, I don't fully understand the reason why those two lines were 
originally included and wonder what the risks are of breaking resizing 
with older NTFS partitions.

I'd suggest uploading to experimental first and doing a "call for testing" 
to see if people experience any problems resizing NT, win2k or winXP (and 
of course Vista) partitions before uploading the new version to unstable.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #638 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org

Subject: Re: Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Wed, 6 Dec 2006 09:39:05 +0100

[Message part 1 (text/plain, inline)]

El miércoles, 6 de diciembre de 2006 00:38, Frans Pop escribió:
> On Tuesday 05 December 2006 00:06, David Martínez Moreno wrote:
> > 	Frans, I think that, not having a better solution, I am going to apply
> > the two-line patch to linux-ntfs and release a new version, is it fine
> > for you?
>
> Yes, that would be fine with me.
> However, I don't fully understand the reason why those two lines were
> originally included and wonder what the risks are of breaking resizing
> with older NTFS partitions.

	It seems that they (MS) have the same 'policy' that we have: do not allow 
upgrades from two releases ahead. :-)  I guess that Vista does not like the 
existance of the NT4 flag, as if it were an indication of subtle differences 
in the underliying filesystem with the format it knows.  And it refuses to 
boot in such partition.

	And the problem that Szaka refers to, if I understood right, is that yes, 
Vista now boots, but perhaps say NT have troubles *not* having this flag in 
its boot partition.

> I'd suggest uploading to experimental first and doing a "call for testing"
> to see if people experience any problems resizing NT, win2k or winXP (and
> of course Vista) partitions before uploading the new version to unstable.

	Seems rational.  I will prepare the new package.

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #643 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sat, 09 Dec 2006 16:42:13 +1100

[Message part 1 (text/plain, inline)]

Ok, I've now also successfully tested this with win2000 in addition to
Vista in response to Frans' concern. 

Szaka,

I would assume that your patch should work for XP and 2003 as well. Do
you agree?

What about NT4? (VOLUME_MOUNTED_ON_NT4 appears to be some sort of
compatibility flag?)

Cheers,
Andree


On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote:
> On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:
> 
> > Apparently Vista refuses to boot if an NTFS volume was mounted on 
> > NT4 earlier. This is also what ntfsresize lied to trick Windows 
> > to be compatible with "itself". 
> > 
> > Could you please try the below patch against ntfsprogs 1.13.1 that the 
> > theory is correct? Thank you.
> 
> I put a statically linked version here to ease the testing.
> 
> 	http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> 
> Thanks,
> 	Szaka
> 
> > --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.000000000 +0200
> > +++ ntfsprogs/ntfsresize.c      2006-12-02 00:09:44.058395088 +0200
> > @@ -2289,8 +2289,6 @@
> >         u16 flags;
> > 
> >         flags = vol->flags | VOLUME_IS_DIRTY;
> > -       if (vol->major_ver >= 2)
> > -               flags |= VOLUME_MOUNTED_ON_NT4;
> > 
> >         printf("Schedule chkdsk for NTFS consistency check at Windows "
> >                 "boot time ...\n");
> > 
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #648 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Andree Leidenfrost <andree@debian.org>

To: Szakacsits Szabolcs <szaka@sienet.hu>, Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org

Subject: [Fwd: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing]

Date: Sun, 10 Dec 2006 13:31:20 +1100

[Message part 1 (text/plain, inline)]

Hm, reading through the entire bug report again (I only subscribed to it
sometime yesterday, so didn't get the messages, sorry) I now understand
that:

- Anton thinks it is safe to not set the VOLUME_MOUNTED_ON_NT4 ever in 
  ntfsresize.
- Szaka believes it might not be safe and wants confirmation from MS.
- David volunteered to take this up with an internal contact at MS if 
  he were to receive a summary of the issue at hand.
- David later suggested to just apply the patch and release a new 
  Debian package
- Frans cautioned that upload to experimental first would be better 
  which David agreed to do

Any ETA for this, David? I'm more than happy to test the package once it
hits experimental. (Sorry for the hassling!)

(I understand that there is also #380226, but taking one step at a time
probably makes for a good approach.)

Cheers,
Andree

-------- Forwarded Message --------
From: Andree Leidenfrost <andree@debian.org>
To: Szakacsits Szabolcs <szaka@sienet.hu>, 379628@bugs.debian.org
Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta
compatibility testing
Date: Sat, 09 Dec 2006 16:42:13 +1100
Ok, I've now also successfully tested this with win2000 in addition to
Vista in response to Frans' concern. 

Szaka,

I would assume that your patch should work for XP and 2003 as well. Do
you agree?

What about NT4? (VOLUME_MOUNTED_ON_NT4 appears to be some sort of
compatibility flag?)

Cheers,
Andree


On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote:
> On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote:
> 
> > Apparently Vista refuses to boot if an NTFS volume was mounted on 
> > NT4 earlier. This is also what ntfsresize lied to trick Windows 
> > to be compatible with "itself". 
> > 
> > Could you please try the below patch against ntfsprogs 1.13.1 that the 
> > theory is correct? Thank you.
> 
> I put a statically linked version here to ease the testing.
> 
> 	http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz
> 
> Thanks,
> 	Szaka
> 
> > --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.000000000 +0200
> > +++ ntfsprogs/ntfsresize.c      2006-12-02 00:09:44.058395088 +0200
> > @@ -2289,8 +2289,6 @@
> >         u16 flags;
> > 
> >         flags = vol->flags | VOLUME_IS_DIRTY;
> > -       if (vol->major_ver >= 2)
> > -               flags |= VOLUME_MOUNTED_ON_NT4;
> > 
> >         printf("Schedule chkdsk for NTFS consistency check at Windows "
> >                 "boot time ...\n");
> > 
-- 
Andree Leidenfrost
@ Debian Developer
Sydney - Australia

[signature.asc (application/pgp-signature, inline)]

Message #653 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 10 Dec 2006 14:27:31 +0200 (MET DST)

Hi,

On Sun, 10 Dec 2006, Andree Leidenfrost wrote:

> - Szaka believes it might not be safe and wants confirmation from MS.

No for the second part. I wrote:

 "I'm not aware of such problem but that doesn't mean there can't be any.
  So you may or may not be right but me being over paranoid about 
  reliability I stick to the latter for now. Though an explicit and 
  official guarantee from Microsoft could change my standpoint."

I don't __want__ confirmation. But I would __accept__ such official 
guarantee to speed up things and for the reason that all the responsibility 
would go to Microsoft if they weren't right.

The alternative way is if we investigate it (and to be honest, this is a 
bit more work then just resizing and booting Windows to see if it still 
works). This takes time, none of us has at the busy end of the year (in the 
family, at work, many social happenings, other responsibilities, everyday
life issues, etc).

I kindly asked some people to test the situation. So far you were the only 
one who replied. Luckily you used W2K. I hopefully can investigate the 
situation with XP today sometime. It takes at least an hour.

But there is another problem with the current ntfsresize cvs. The changes 
to ntfsresize seems to be safe now (had no time to check this in detail 
yet) but all my ntfsresize regression tests fail. All resized images were 
always checksummed in the last 4+ years but they are incorrect now. Partly 
this is due to the NT4 flag change but I noticed this problem earlier, and 
I think it should be investigated.

I'll put one of my tests somewhere, so somebody with enough free time could 
do the analyzes. The root cause could be completely irrelevant but it could 
be also serious.

On the positive side, this week I got a few additional feedbacks that the 
old ntfsresize had bootability problem with Vista Gold for others too but 
ntfsresize-1.13.1.1 worked.

> - David volunteered to take this up with an internal contact at MS if 
>   he were to receive a summary of the issue at hand.

He also wrote that it wouldn't be official, and I definitely don't want to 
get involved acquiring unofficial, unauthorized internal Microsoft 
information. Reverse engineering is legal but I believe not the latter one.

> I'm more than happy to test the package once it hits experimental.

Thank you Andree. You already helped quite a lot during this very critical 
time, it's appreciated a lot.

Cheers,
		Szaka

Message #658 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 10 Dec 2006 18:46:23 +0200 (MET DST)

On Sun, 10 Dec 2006, Szakacsits Szabolcs wrote:

> The alternative way is if we investigate it (and to be honest, this is a 
> bit more work then just resizing and booting Windows to see if it still 
> works). This takes time, none of us has at the busy end of the year (in the 
> family, at work, many social happenings, other responsibilities, everyday
> life issues, etc).
> 
> I kindly asked some people to test the situation. So far you were the only 
> one who replied. Luckily you used W2K. I hopefully can investigate the 
> situation with XP today sometime. It takes at least an hour.

Below are all the normalized differences between two XP NTFS volumes 
which were completely identical originally and were resulted after 
running chkdsk on them and which were resized with and without using 
the VOLUME_MOUNTED_ON_NT4 flag:

   Dumping Inode 0
  -Upd. Seq. Number:       11
  +Upd. Seq. Number:       10
   Dumping Inode 1
  -Upd. Seq. Number:       9
  +Upd. Seq. Number:       8
   Dumping Inode 2
  -Upd. Seq. Number:       8
  +Upd. Seq. Number:       7
   Dumping Inode 3
  -Upd. Seq. Number:       11
  -LogFile Seq. Number:    0x200916
  +Upd. Seq. Number:       10
  +LogFile Seq. Number:    0x200872
   Dumping Inode 5
  -LogFile Seq. Number:    0x2011b4
  +LogFile Seq. Number:    0x200f8f
          Dumping index block:
  -               LogFile Seq. Number:     0x200e68
  +               LogFile Seq. Number:     0x200dbc

This output suggests to me that changing the two relevant flags in 
$VOLUME_INFORMATION are done per logfile transaction.

As a conclusion, this also suggests, that my two liner patch to 
ntfsprogs-1.13.1 seems to be safe for all versions of Windows.
 
More later.
		Szaka

Message #663 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Szakacsits Szabolcs <szaka@sienet.hu>

To: Andree Leidenfrost <andree@debian.org>

Cc: Anton Altaparmakov <aia21@cam.ac.uk>, 379628@bugs.debian.org, Linux-NTFS-Dev@lists.sourceforge.net

Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

Date: Sun, 10 Dec 2006 22:52:23 +0200 (MET DST)

On Sun, 10 Dec 2006, Szakacsits Szabolcs wrote:

> But there is another problem with the current ntfsresize cvs. The changes 
> to ntfsresize seems to be safe now (had no time to check this in detail 
> yet) but all my ntfsresize regression tests fail. All resized images were 
> always checksummed in the last 4+ years but they are incorrect now. Partly 
> this is due to the NT4 flag change but I noticed this problem earlier, and 
> I think it should be investigated.
> 
> I'll put one of my tests somewhere, so somebody with enough free time could 
> do the analyzes. The root cause could be completely irrelevant but it could 
> be also serious.

Some words on ntfsresize design first. Ntfsresize tried to be 
self-contained, that is having minimal dependency on libntfs, 
and use only well-tested and revised libntfs functions, for 
several reasons:

 o  It works differently than the other tools.

 o  Functionalities weren't written yet in libntfs what I had to write
    but my priority was to have a reliable NTFS resizer asap, so I focused
    only on things what the resizer needed.

 o  No interference with libntfs development: most libntfs bugs were 
    irrelevant to ntfsresize.

In other words, there was no need to worry much about the reliability of 
ntfsresize because the chance to break it accidentally was minimal and the 
regression tests gave the same MD5s most of the time.

I've checked why the regressions fail with current ntfsprogs cvs. I have 
found only two reasons.

 1. md5sum(1) is calculated based on the ntfsclone special image 
    format. However ntfclone signature was changed in the cvs and 
    this obviously resulted different MD5s. No problem here.

 2. Dumping Inode 3
     -Upd. Seq. Number:       17
     +Upd. Seq. Number:       3

    This is due to the DIRTY flag is conditionally marked now. If it was 
    dirty then it's not marked, mft record not updated, USN not increased. 
    This is not a problem for volume consistency point of view. However.

    I __intentionally__ made the dirty flag setting and the journal 
    resetting unconditional for two reasons:

      1. The DIRTY flag is very critical for data integrity point of view 
         in case of recovery, for example if a disaster happen (e.g. power 
         outage). The saving of this operation is not worth, for example 
         if there is a bug in the DIRTY flag (or journal cleanness) 
         checking code. It was a reliability/robustness vs speed decision. 
         The first one was highly preferred for me against the second one.

      2. These two operations also served as unconditionally sanity 
         check the volume and the most important NTFS metadata writability. 
         If something went wrong in the early stage then spotting the 
         problem was trivial. Otherwise it could have happened anywhere 
         and the troubleshooting could have caused more time.

Regards,
	Szaka

Message #668 received at 379628-close@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: 379628-close@bugs.debian.org

Subject: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Thu, 21 Dec 2006 18:02:02 +0000

Source: linux-ntfs
Source-Version: 1.13.1-5

We believe that the bug you reported is fixed in the latest version of
linux-ntfs, which is due to be installed in the Debian FTP archive:

libntfs-dev_1.13.1-5_i386.deb
  to pool/main/l/linux-ntfs/libntfs-dev_1.13.1-5_i386.deb
libntfs-gnomevfs_1.13.1-5_i386.deb
  to pool/main/l/linux-ntfs/libntfs-gnomevfs_1.13.1-5_i386.deb
libntfs9_1.13.1-5_i386.deb
  to pool/main/l/linux-ntfs/libntfs9_1.13.1-5_i386.deb
linux-ntfs_1.13.1-5.diff.gz
  to pool/main/l/linux-ntfs/linux-ntfs_1.13.1-5.diff.gz
linux-ntfs_1.13.1-5.dsc
  to pool/main/l/linux-ntfs/linux-ntfs_1.13.1-5.dsc
ntfsprogs-udeb_1.13.1-5_i386.udeb
  to pool/main/l/linux-ntfs/ntfsprogs-udeb_1.13.1-5_i386.udeb
ntfsprogs_1.13.1-5_i386.deb
  to pool/main/l/linux-ntfs/ntfsprogs_1.13.1-5_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 379628@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
David Martínez Moreno <ender@debian.org> (supplier of updated linux-ntfs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 21 Dec 2006 18:47:48 +0100
Source: linux-ntfs
Binary: libntfs9 ntfsprogs-udeb ntfsprogs libntfs-dev libntfs-gnomevfs
Architecture: source i386
Version: 1.13.1-5
Distribution: experimental
Urgency: high
Maintainer: David Martínez Moreno <ender@debian.org>
Changed-By: David Martínez Moreno <ender@debian.org>
Description: 
 libntfs-dev - library that provides common NTFS access functions (development f
 libntfs-gnomevfs - NTFS GNOME virtual filesystem module
 libntfs9   - library that provides common NTFS access functions
 ntfsprogs  - tools for doing neat things in NTFS partitions from Linux
 ntfsprogs-udeb - Tools for doing neat things in NTFS partitions from Linux - udeb (udeb)
Closes: 379628
Changes: 
 linux-ntfs (1.13.1-5) experimental; urgency=high
 .
   * Patched ntfsprogs/ntfsresize.c in order to fix grave resizing problem of
     Vista partitions.  Let's try before in experimental...  Many thanks to
     Szakacsits Szabolcs for the patch (closes: #379628).
Files: 
 8bc6b39a49bce15ff957c1528d5bcdfa 698 otherosfs optional linux-ntfs_1.13.1-5.dsc
 eb600ffa436095e09ce4b9276571516d 12867 otherosfs optional linux-ntfs_1.13.1-5.diff.gz
 90c6f71afe0eff47ae39081539d48798 283940 otherosfs optional ntfsprogs_1.13.1-5_i386.deb
 f39d5c0c5d552695a29bb9c8dbba61be 113808 debian-installer optional ntfsprogs-udeb_1.13.1-5_i386.udeb
 826376ea94681e4e2828e6e12fdc9ca2 51748 libs optional libntfs-gnomevfs_1.13.1-5_i386.deb
 16f1cff2b2f84709f6abb7481ce2d500 136270 libs optional libntfs9_1.13.1-5_i386.deb
 e91915e2557b14f374ca0e1e7b757abc 217636 libdevel optional libntfs-dev_1.13.1-5_i386.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFisk8Ws/EhA1iABsRAnJZAKCY89WTby5oj3VCp6wAHeGEYd5o9wCgj/It
f1uOR2RywvrjMuw31d/3F6U=
=GCqH
-----END PGP SIGNATURE-----

Message #669 received at 379628-close@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: David Martínez Moreno <ender@debian.org>

Cc: 379628-close@bugs.debian.org

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Sun, 31 Dec 2006 11:09:29 +0100

* David Martínez Moreno (ender@debian.org) [061221 10:17]:
> Changes: 
>  linux-ntfs (1.13.1-5) experimental; urgency=high
>  .
>    * Patched ntfsprogs/ntfsresize.c in order to fix grave resizing problem of
>      Vista partitions.  Let's try before in experimental...  Many thanks to
>      Szakacsits Szabolcs for the patch (closes: #379628).

How about uploading the fix as well to unstable?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

Message #674 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Andreas Barth <aba@not.so.argh.org>

Cc: 379628@bugs.debian.org, ender@debian.org

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Mon, 1 Jan 2007 14:02:25 +0100

[Message part 1 (text/plain, inline)]

El domingo, 31 de diciembre de 2006 11:09, Andreas Barth escribió:
> * David Martínez Moreno (ender@debian.org) [061221 10:17]:
> > Changes:
> >  linux-ntfs (1.13.1-5) experimental; urgency=high
> >  .
> >    * Patched ntfsprogs/ntfsresize.c in order to fix grave resizing
> > problem of Vista partitions.  Let's try before in experimental...  Many
> > thanks to Szakacsits Szabolcs for the patch (closes: #379628).
>
> How about uploading the fix as well to unstable?

	Hello, Andi.

	As far as I can tell, Frans wanted to upload this fix first to experimental, 
give it a wider testing, and then put it into unstable.  So I am really 
waiting for the green light. :-)  Should I proceed?

	Best regards, and happy new year,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #679 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org, David Martínez Moreno <ender@debian.org>

Cc: Andreas Barth <aba@not.so.argh.org>

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Mon, 01 Jan 2007 14:56:13 +0100

[Message part 1 (text/plain, inline)]

On Monday 01 January 2007 14:02, David Martínez Moreno wrote:
> > How about uploading the fix as well to unstable?
>
> 	Hello, Andi.
>
> 	As far as I can tell, Frans wanted to upload this fix first to
> experimental, give it a wider testing, and then put it into unstable. 
> So I am really waiting for the green light. :-)  Should I proceed?

Hmm. The only thing is that I never saw an actual call for testing.
I would have expected something on d-d-a. That would have given others a 
chance to actually do targeted testing...

Probably just a misunderstanding.

I'm fairly swamped myself ATM, so I'll leave it to you and the RMs to 
decide if you want to upload to unstable now or not.

Cheers,
FJP

[Message part 2 (application/pgp-signature, inline)]

Message #684 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Frans Pop <elendil@planet.nl>, 379628@bugs.debian.org

Cc: David Martínez Moreno <ender@debian.org>, Andreas Barth <aba@not.so.argh.org>

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Mon, 1 Jan 2007 13:35:39 -0800

On Mon, Jan 01, 2007 at 02:56:13PM +0100, Frans Pop wrote:
> On Monday 01 January 2007 14:02, David Martínez Moreno wrote:
> > > How about uploading the fix as well to unstable?

> > 	As far as I can tell, Frans wanted to upload this fix first to
> > experimental, give it a wider testing, and then put it into unstable. 
> > So I am really waiting for the green light. :-)  Should I proceed?

> Hmm. The only thing is that I never saw an actual call for testing.
> I would have expected something on d-d-a. That would have given others a 
> chance to actually do targeted testing...

> Probably just a misunderstanding.

> I'm fairly swamped myself ATM, so I'll leave it to you and the RMs to 
> decide if you want to upload to unstable now or not.

I don't see any reason why this fix should have ever been uploaded to
experimental instead of unstable in the first place.  Please upload it (the
fix, not the new upstream version) to unstable where it will do us some
good.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #689 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Frans Pop <elendil@planet.nl>

Cc: 379628@bugs.debian.org, Andreas Barth <aba@not.so.argh.org>, ender@debian.org

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Tue, 2 Jan 2007 12:14:51 +0100

[Message part 1 (text/plain, inline)]

El lunes, 1 de enero de 2007 14:56, Frans Pop escribió:
> On Monday 01 January 2007 14:02, David Martínez Moreno wrote:
> > > How about uploading the fix as well to unstable?
> >
> > 	Hello, Andi.
> >
> > 	As far as I can tell, Frans wanted to upload this fix first to
> > experimental, give it a wider testing, and then put it into unstable.
> > So I am really waiting for the green light. :-)  Should I proceed?
>
> Hmm. The only thing is that I never saw an actual call for testing.
> I would have expected something on d-d-a. That would have given others a
> chance to actually do targeted testing...
>
> Probably just a misunderstanding.

	Probably my fault, sorry.  I supposed (wrongly) that you would send that 
announcement. :-(

	Best regards and happy new year,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #694 received at 379628@bugs.debian.org (full text, mbox, reply):

From: David Martínez Moreno <ender@debian.org>

To: Steve Langasek <vorlon@debian.org>, 379628@bugs.debian.org

Cc: Frans Pop <elendil@planet.nl>, Andreas Barth <aba@not.so.argh.org>

Subject: Re: Bug#379628: fixed in linux-ntfs 1.13.1-5

Date: Tue, 2 Jan 2007 12:18:48 +0100

[Message part 1 (text/plain, inline)]

El lunes, 1 de enero de 2007 22:35, Steve Langasek escribió:
> I don't see any reason why this fix should have ever been uploaded to
> experimental instead of unstable in the first place.  Please upload it (the
> fix, not the new upstream version) to unstable where it will do us some
> good.

	There it goes. :-)

	Best regards,


		Ender.
-- 
Network engineer
Debian Developer

[Message part 2 (application/pgp-signature, inline)]

Message #699 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Kenshi Muto <kmuto@debian.org>

To: 379628@bugs.debian.org

Subject: Re: #379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Sat, 10 Feb 2007 12:27:11 +0900

reopen 379628
found 1.13.1-6
thanks

I'm sorry to reopen this bug, but this problem happened again
on my d-i test environment.

[Test environment]
- Windows Vista Ultimate (MSDN) on VMware i386 (1024MB memory)
  18GB sda (SCSI LSI53C1030 emulation)
  and filled by Vista as /dev/sda1
- netinst.iso Debian GNU/Linux testing "Etch" - Official Snapshot i386 NETINST Binary-1 20070209-21:47
  includes ntfsprogs-udeb_1.13.1-6_i386.udeb
- Removed "exit 1" from partman resize.sh to skip Vista-check.
- Booted installer and tried resizing sda1 from 18GB to 10GB on partman menu.

[Result]
It made corrutpted NTFS filesystem. I can't boot/mount/read Windows no
more. Rebooting doesn't help it.

[Log]
 ...
Feb 10 11:12:09 anna[4318]: DEBUG: ask for ntfs-modules-2.6.18-4-486-di, matches kernel
 ...
Feb 10 11:16:16 ntfsresize: ntfsresize v1.13.1 (libntfs 9:0:0)
Feb 10 11:16:16 ntfsresize: Device name        : /dev/scsi/host0/bus0/target0/lun0/part1
Feb 10 11:16:16 ntfsresize: NTFS volume version: 3.1
Feb 10 11:16:16 ntfsresize: Cluster size       : 4096 bytes
Feb 10 11:16:16 ntfsresize: Current volume size: 19325252096 bytes (19326 MB)
Feb 10 11:16:16 ntfsresize: Current device size: 19325255680 bytes (19326 MB)
Feb 10 11:16:16 ntfsresize: Checking filesystem consistency ...
Feb 10 11:16:16 ntfsresize: Accounting clusters ...
Feb 10 11:16:16 ntfsresize: Space in use       : 8712 MB (45.1%)
Feb 10 11:16:16 ntfsresize: Collecting resizing constraints ...
Feb 10 11:16:16 ntfsresize: You might resize at 8711770112 bytes or 8712 MB (freeing 10614 MB).
Feb 10 11:16:16 ntfsresize: Please make a test run using both the -n and -s options before real resizing!
Feb 10 11:16:16 anna-install: Installing ntfs-modules
Feb 10 11:16:16 anna[10587]: DEBUG: resolver (kernel-image-2.6.18-4-486-di): package doesn't exist (ignored)
Feb 10 11:16:16 kernel: NTFS driver 2.1.27 [Flags: R/W MODULE].
Feb 10 11:16:16 kernel: NTFS volume version 3.1.
Feb 10 11:16:16 partman: Partition /dev/sda1 contains Windows Vista
Feb 10 11:16:16 partman: Resizing of Vista NTFS partitions is not supported
Feb 10 11:16:16 partman: See http://bugs.debian.org/379835 for details
Feb 10 11:16:28 init: Starting pid 1036, console /dev/vc/2: '/bin/sh'
Feb 10 11:17:02 ntfsresize: ntfsresize v1.13.1 (libntfs 9:0:0)
Feb 10 11:17:02 ntfsresize: Device name        : /dev/scsi/host0/bus0/target0/lun0/part1
Feb 10 11:17:02 ntfsresize: NTFS volume version: 3.1
Feb 10 11:17:02 ntfsresize: Cluster size       : 4096 bytes
Feb 10 11:17:02 ntfsresize: Current volume size: 19325252096 bytes (19326 MB)
Feb 10 11:17:02 ntfsresize: Current device size: 19325255680 bytes (19326 MB)
Feb 10 11:17:02 ntfsresize: Checking filesystem consistency ...
Feb 10 11:17:02 ntfsresize: Accounting clusters ...
Feb 10 11:17:02 ntfsresize: Space in use       : 8712 MB (45.1%)
Feb 10 11:17:02 ntfsresize: Collecting resizing constraints ...
Feb 10 11:17:02 ntfsresize: You might resize at 8711770112 bytes or 8712 MB (freeing 10614 MB).
Feb 10 11:17:02 ntfsresize: Please make a test run using both the -n and -s options before real resizing!
Feb 10 11:17:02 anna-install: Installing ntfs-modules
Feb 10 11:17:02 kernel: NTFS volume version 3.1.
Feb 10 11:17:02 partman: Partition /dev/sda1 contains Windows Vista
Feb 10 11:17:02 partman: Resizing of Vista NTFS partitions is not supported
Feb 10 11:17:02 partman: See http://bugs.debian.org/379835 for details
Feb 10 11:52:19 ntfsresize: ntfsresize v1.13.1 (libntfs 9:0:0)
Feb 10 11:52:19 ntfsresize: Device name        : /dev/scsi/host0/bus0/target0/lun0/part1
Feb 10 11:52:19 ntfsresize: NTFS volume version: 3.1
Feb 10 11:52:19 ntfsresize: Cluster size       : 4096 bytes
Feb 10 11:52:19 ntfsresize: Current volume size: 19325252096 bytes (19326 MB)
Feb 10 11:52:19 ntfsresize: Current device size: 19325255680 bytes (19326 MB)
Feb 10 11:52:19 ntfsresize: New volume size    : 9999995392 bytes (10000 MB)
Feb 10 11:52:19 ntfsresize: Checking filesystem consistency ...
Feb 10 11:52:19 ntfsresize: Accounting clusters ...
Feb 10 11:52:19 ntfsresize: Space in use       : 8712 MB (45.1%)
Feb 10 11:52:19 ntfsresize: Collecting resizing constraints ...
Feb 10 11:52:19 ntfsresize: Needed relocations : 384236 (1574 MB)
Feb 10 11:52:19 ntfsresize: Schedule chkdsk for NTFS consistency check at Windows boot time ...
Feb 10 11:52:19 ntfsresize: Resetting $LogFile ... (this might take a while)
Feb 10 11:52:19 ntfsresize: Relocating needed data ...
Feb 10 11:52:19 ntfsresize: Updating $BadClust file ...
Feb 10 11:52:19 ntfsresize: Updating $Bitmap file ...
Feb 10 11:52:19 ntfsresize: Updating Boot record ...
Feb 10 11:52:19 ntfsresize: Syncing device ...
Feb 10 11:52:19 ntfsresize: Successfully resized NTFS on device '/dev/scsi/host0/bus0/target0/lun0/part1'.
Feb 10 11:52:19 ntfsresize: You can go on to shrink the device for example with Linux fdisk.
Feb 10 11:52:19 ntfsresize: IMPORTANT: When recreating the partition, make sure that you
Feb 10 11:52:19 ntfsresize:   1)  create it at the same disk sector (use sector as the unit!)
Feb 10 11:52:19 ntfsresize:   2)  create it with the same partition type (usually 7, HPFS/NTFS)
Feb 10 11:52:19 ntfsresize:   3)  do not make it smaller than the new NTFS filesystem size
Feb 10 11:52:19 ntfsresize:   4)  set the bootable flag for the partition if it
existed before
Feb 10 11:52:19 ntfsresize: Otherwise you won't be able to access NTFS or can't
boot from the disk!
Feb 10 11:52:19 ntfsresize: If you make a mistake and don't have a partition table backup then you
Feb 10 11:52:19 ntfsresize: can recover the partition table by TestDisk or Parted's rescue mode.
Feb 10 11:52:19 ntfsresize: ntfsresize v1.13.1 (libntfs 9:0:0)
Feb 10 11:52:19 ntfsresize: ERROR(2): Failed to check '/dev/scsi/host0/bus0/target0/lun0/part1' mount state: No such file or directory
Feb 10 11:52:19 ntfsresize: Probably /etc/mtab is missing. It's too risky to continue. You might try
Feb 10 11:52:19 ntfsresize: an another Linux distro.
Feb 10 11:52:19 partman: Error resizing the NTFS file system to the partition size

partman shows:
SCSI1 (0,0,0) (sda) - 19.3 GB VMware, VMware Virtual S
      1. primary  10.0 GB B
         pri/log   9.3 GB    FREE SPACE

Thanks,
-- 
Kenshi Muto
kmuto@debian.org

Message #706 received at 379628@bugs.debian.org (full text, mbox, reply):

From: Frans Pop <elendil@planet.nl>

To: 379628@bugs.debian.org

Cc: Kenshi Muto <kmuto@debian.org>

Subject: Re: Bug#379628: #379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition

Date: Sat, 10 Feb 2007 19:16:40 +0100

[Message part 1 (text/plain, inline)]

close 379628
thanks

> I'm sorry to reopen this bug, but this problem happened again
> on my d-i test environment.

No, that is almost certainly not this bug but #380226. That bug is also 
the reason why #379835 is still open (though not at RC priority because 
of the block currently programmed in partman).

Closing again.

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.