Bug#397364: [ntfs-3g-devel] ntfs-3g-0.20070116-BETA
On Wed, 17 Jan 2007 [EMAIL PROTECTED] wrote: > > This effects many other distributions and people often ask what's happening. > > Adam Cecile, Mertens Florent and me offered to help the Debian maintainer, > > and Flo sent an LSB compliant FUSE init file but the maintainer doesn't > > reply repeated emails for some reason for about a month, so the FUSE upgrade > > process stuck unfortunately. > > > > I think the solution could be to have a FUSE Debian co-maintainer. > > Some fresh news on this issue. It seams that a new fuse package is > nearly ready in debian : > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404240 > > "I talked to Bartosz Fenski (fuse package) and his fuse 2.6 package is > nearly ready. He hopes he will be able to upload during this week. > > I will upload update ntfs-3g asap. > > Regards, Adam." Any FUSE development? Debian users are submitting old problems which were solved months ago ... Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397364: ntfs-3g-0.20070116-BETA
Hi, On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: > It was a good idea to support older fuse kernel modules, but it still > requires new fuse user space tools to compile. Is it possible to > compile/use with fuse 2.5.3 too? Currently there is a check for 2.6.0+ > in the configure script. Correct. FUSE 2.6 user space is backward comaptible and upgrades went smoothly for distros. Except for Debian because the optionally provided FUSE init script isn't LSB compliant. This effects many other distributions and people often ask what's happening. Adam Cecile, Mertens Florent and me offered to help the Debian maintainer, and Flo sent an LSB compliant FUSE init file but the maintainer doesn't reply repeated emails for some reason for about a month, so the FUSE upgrade process stuck unfortunately. I think the solution could be to have a FUSE Debian co-maintainer. 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
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
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
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
> 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
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
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 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, 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, 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, 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 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] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- 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, 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
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: Bug#379628: CALL FOR HELP: Vista beta compatibility testing
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 -- 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
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 (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]
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] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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 -- 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] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: ntfsresize: resizing a Vista NTFS partition ...)
[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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: ntfsresize: resizing a Vista NTFS partition ...)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)
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 > > 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 > > after which you should see a message like: > > "NTFS had been successfully resized on device " > > 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 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#395901: FTBFS (alpha): va_list abuse
> Please feel free to remove the offending 'args = NULL;' lines. It's part
> of a dead, unused, broken functionality. It will be fixed properly in the
> next ntfs-3g release.
Hi. Attached is the complete ntfs-3g fix. Compile tested only on x86.
Thanks,
SzakaIndex: include/ntfs-3g/logging.h
===
RCS file: /home/szaka/devel/CVS/ntfs-3g/include/ntfs-3g/logging.h,v
retrieving revision 1.2
diff -u -d -p -r1.2 logging.h
--- include/ntfs-3g/logging.h 29 Oct 2006 01:18:57 - 1.2
+++ include/ntfs-3g/logging.h 29 Oct 2006 01:57:38 -
@@ -75,7 +75,6 @@ int ntfs_log_redirect(const char *functi
#define NTFS_LOG_LEVEL_ERROR (1 << 7) /* Operation failed, no damage done */
#define NTFS_LOG_LEVEL_PERROR (1 << 8) /* Message : standard error
description */
#define NTFS_LOG_LEVEL_CRITICAL(1 << 9) /* Operation failed,damage
may have occurred */
-#define NTFS_LOG_LEVEL_REASON (1 << 10) /* Human readable reason for failure
*/
/* Logging style flags - Manage the style of the output */
#define NTFS_LOG_FLAG_PREFIX (1 << 0) /* Prefix messages with "ERROR: ", etc
*/
@@ -96,7 +95,6 @@ int ntfs_log_redirect(const char *functi
#define ntfs_log_quiet(FORMAT, ARGS...)
ntfs_log_redirect(__FUNCTION__,__FILE__,__LINE__,NTFS_LOG_LEVEL_QUIET,NULL,FORMAT,##ARGS)
#define ntfs_log_verbose(FORMAT, ARGS...)
ntfs_log_redirect(__FUNCTION__,__FILE__,__LINE__,NTFS_LOG_LEVEL_VERBOSE,NULL,FORMAT,##ARGS)
#define ntfs_log_warning(FORMAT, ARGS...)
ntfs_log_redirect(__FUNCTION__,__FILE__,__LINE__,NTFS_LOG_LEVEL_WARNING,NULL,FORMAT,##ARGS)
-#define ntfs_log_reason(FORMAT, ARGS...)
ntfs_log_redirect(__FUNCTION__,__FILE__,__LINE__,NTFS_LOG_LEVEL_REASON,NULL,FORMAT,##ARGS)
/* By default debug and trace messages are compiled into the program,
* but not displayed.
cvs diff: Diffing libntfs-3g
Index: libntfs-3g/logging.c
===
RCS file: /home/szaka/devel/CVS/ntfs-3g/libntfs-3g/logging.c,v
retrieving revision 1.2
diff -u -d -p -r1.2 logging.c
--- libntfs-3g/logging.c29 Oct 2006 01:18:57 - 1.2
+++ libntfs-3g/logging.c29 Oct 2006 01:57:38 -
@@ -80,7 +80,7 @@ static struct ntfs_logging ntfs_log = {
#endif
NTFS_LOG_LEVEL_INFO | NTFS_LOG_LEVEL_QUIET | NTFS_LOG_LEVEL_WARNING |
NTFS_LOG_LEVEL_ERROR | NTFS_LOG_LEVEL_PERROR | NTFS_LOG_LEVEL_CRITICAL |
- NTFS_LOG_LEVEL_REASON | NTFS_LOG_LEVEL_PROGRESS,
+ NTFS_LOG_LEVEL_PROGRESS,
NTFS_LOG_FLAG_ONLYNAME,
#ifdef DEBUG
ntfs_log_handler_outerr
@@ -349,26 +349,9 @@ int ntfs_log_handler_syslog(const char *
const char *file, __attribute__((unused)) int line, u32 level,
void *data __attribute__((unused)), const char *format, va_list args)
{
- const int reason_size = 128;
- static char *reason = NULL;
int ret = 0;
int olderr = errno;
- if (level == NTFS_LOG_LEVEL_REASON) {
- if (!reason)
- reason = ntfs_malloc(reason_size);
- if (reason) {
- memset(reason, 0, reason_size);
- return vsnprintf(reason, reason_size, format, args);
- } else {
- /* Rather than call ourselves, just drop through */
- level = NTFS_LOG_LEVEL_PERROR;
- format = "Couldn't create reason";
- args = NULL;
- olderr = errno;
- }
- }
-
if ((ntfs_log.flags & NTFS_LOG_FLAG_ONLYNAME) &&
(strchr(file, PATH_SEP))) /* Abbreviate the filename */
file = strrchr(file, PATH_SEP) + 1;
@@ -427,8 +410,6 @@ int ntfs_log_handler_syslog(const char *
int ntfs_log_handler_fprintf(const char *function, const char *file,
int line, u32 level, void *data, const char *format, va_list args)
{
- const int reason_size = 128;
- static char *reason = NULL;
int ret = 0;
int olderr = errno;
FILE *stream;
@@ -439,21 +420,6 @@ int ntfs_log_handler_fprintf(const char
return 0; /* If it's NULL, we can't do anything. */
stream = (FILE*)data;
- if (level == NTFS_LOG_LEVEL_REASON) {
- if (!reason)
- reason = ntfs_malloc(reason_size);
- if (reason) {
- memset(reason, 0, reason_size);
- return vsnprintf(reason, reason_size, format, args);
- } else {
- /* Rather than call ourselves, just drop through */
- level = NTFS_LOG_LEVEL_PERROR;
- format = "Couldn't create reason";
- args = NULL;
- olderr = errno;
- }
- }
-
if (ntfs_log.flags & NTFS_LOG_FLAG_COLOUR) {
/* Pick a
Bug#395901: FTBFS (alpha): va_list abuse
Hi, Please feel free to remove the offending 'args = NULL;' lines. It's part of a dead, unused, broken functionality. It will be fixed properly in the next ntfs-3g release. Thank you, Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)
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 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 after which you should see a message like: "NTFS had been successfully resized on device " 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390778: ITP: ntfs-3g -- A read-write NTFS driver for FUSE
On Fri, 6 Oct 2006, Adam [iso-8859-1] C?cile (Le_Vert) wrote: > Okay i386, amd64 (unofficial) supported. Great. What's about 32 bits > little-endian other arches, I mean arm and mipsel ? Any feedbacks ? Arm and hppa has fuse problems. No more arch related info yet. > I can give you ssh root access on an old sparc station (ultra5) with 80Gb > hard > disk. Feel free to ask for it if yu think it can ben helpful ! Thanks, noted :) One day I may pop up for this ;) Szaka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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: 1194368 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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: 1194368 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 > > > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379628: [Linux-NTFS-Dev] Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350679: ntfsprogs: ntfsresize slow for simple query
On Fri, 14 Jul 2006, David [iso-8859-1] Mart?nez Moreno wrote: > El mi?rcoles, 1 de febrero de 2006 06:31, Ross Boylan escribi?: > > On Tue, Jan 31, 2006 at 02:28:35PM +0100, Szakacsits Szabolcs wrote: > [...] > > Hello, Ross. I am packaging the just released 1.13.1 version of > ntfsprogs > and I am taking care of open bug reports. Do you really have problems yet > with this? I'm collecting the reasons why ntfsresize may be slow on some systems here: http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html#slow All of them is either hardware or hardware setup problem. Szaka > > > > It appears that a lot of checks are taking place, so maybe this is a > > > > good thing. But maybe not, hence this report. > > > > > > The checks are intentional and it can take such long time if the size of > > > the $MFT is big enough or you have IDE DMA disabled (see, hdpram > > > /dev/hda). > > > > Is hdpram a program? I can't find it, or any closely related spelling, > > in the Debian archives. > > Well, Szaka really meant hdparm. If you are experiencing this issue > yet, > please run as root 'hdparm -i /dev/hda' and 'ntfsresize -i -f /dev/hda7', and > post the results to [EMAIL PROTECTED] I am not seeing any problem with > at least five different NTFS partitions, and ntfsclone reads them in one > second or two. > > Thanks in advance, > > > Ender. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
