Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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= bs=512 count=1 | dd of= seek= > > where is the last sector on . It can be calculated > by running > > sfdisk -d | grep > > 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 Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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? pgpRUA8sUdlUk.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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.0 +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");
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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.0 +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");
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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. pgpcCAMMm8LL0.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpAOKAvS7ot0.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
> 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
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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.0 +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
Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpMOrS47Wj9j.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpMRTQ4BfwWQ.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpx3ZFMCSCx9.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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. pgpVZGLaEgwOG.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgp6Pix6tOfkQ.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpi18kkFl5ME.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 pgpOqjBm4va50.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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.0 +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
Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
Hi, Could you please try this after running ntfsresize and before booting Vista: dd if= bs=512 count=1 | dd of= seek= where is the last sector on . It can be calculated by running sfdisk -d | grep and then by subtracting 1 from the value of 'size'. Please let me know if this makes Vista boot or not. Thanks, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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. 2968 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= bs=512 count=1 | dd of= seek= This did not work (Vista still unbootable). pgpK4APA5Gl4s.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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. pgpNp7jdO1ITx.pgp Description: PGP signature
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
