Bug 355151

ntfsresize probably shouldn't segfault, but it looks like you've got some NTFS corruption. Please boot into windows and run chkdsk (as the error messages suggest).

This is after running chkdsk /r /v from UBCD4Win-CD on all drives.
MS-Win is reporting NO errors.

Can you provide the output of hwinfo?

Created attachment 192069 [details]
output of hwinfo

o.k. this is the funny ASUS P5W DH Delux!

Maybe, this is of help:
gdb `which ntfsresize` /dev/sda1
GNU gdb 6.7.50.20080110-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
(no debugging symbols found)
"/dev/sda1" is not a core dump: File format not recognized
(gdb) r /dev/sda1
Starting program: /usr/sbin/ntfsresize /dev/sda1
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
ntfsresize v2.0.0 (libntfs 10:0:0)

Program received signal SIGSEGV, Segmentation fault.
0xb7edafd8 in ntfs_volume_startup () from /usr/lib/libntfs.so.10
(gdb)   

O.K.
I went to factory and greped version 2.0.0.6 incl. debug.
ntfsprogs-2.0.0-6
Now I see:
# gdb `which ntfsresize`
GNU gdb 6.7.50.20080110-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
(gdb) r /dev/sda1
Starting program: /usr/sbin/ntfsresize /dev/sda1
ntfsresize v2.0.0 (libntfs 10:0:0)

Program received signal SIGSEGV, Segmentation fault.
0xb7f25f58 in ntfs_volume_startup (dev=0x93f10e0, flags=0) at volume.c:403
403             if (vol->mftmirr_na->rl[0].lcn != vol->mftmirr_lcn ||
(gdb) p vol->mftmirr_lcn
$1 = 16
(gdb) p vol->mftmirr_na->rl[0].lcn
Cannot access memory at address 0x8
(gdb) p *vol->mftmirr_na
$2 = {rl = 0x0, ni = 0x8bc8460, type = AT_DATA, name = 0x8056134, name_len = 0, state = 3, allocated_size = 4096, data_size = 4096, initialized_size = 4096, compressed_size = 0,
  compression_block_size = 0, compression_block_size_bits = 0 '\0', compression_block_clusters = 0 '\0', crypto = 0x0, list_entry = {next = 0x8bc84b4, prev = 0x8bc84b4},
  nr_references = 1}
(gdb)                 

I have Win XP SP2, all bugfixes installed.
HD formated    Jan.08                                                                                

Ok, can you do this then:

$ ntfsclone -m <device> -o ntfs-metadata.img

... and post ntfs-metadata.img somewhere? The -m means only dump the metadata. This both keeps the file smaller and also removes all file contents from the dump. That will help me reproduce it locally so I can debug it.

Oops, actually that produces a sparse file the size of the entire file system. Can you do this as well:

$ tar jcSf ntfs-metadata.img.tar.bz2 ntfs-metadata.img

bzip2, by itself, doesn't handle sparse files especially well. This will probably take a while, but will make the file size much more managable.

 # ntfsclone -m  --ignore-fs-check -f /dev/sda1 -o ntfs-metadata.img
ntfsclone v2.0.0 (libntfs 10:0:0)
Speicherzugriffsfehler

is not of real help!

Knoppix 3.9b as of june 2004 does not have any problems

ntfs-3g does not work too.
vfat partition on /dev/sda6 is mounted without trouble.

I have checked too:

joachim-linux:/home/jre # ldd `which ntfsclone`
        linux-gate.so.1 =>  (0xffffe000)
        libntfs.so.10 => /usr/lib/libntfs.so.10 (0xb7ee2000)
        libc.so.6 => /lib/libc.so.6 (0xb7da1000)
        /lib/ld-linux.so.2 (0xb7f2e000)
joachim-linux:/home/jre # ls -l /usr/lib/libntfs.so.10
lrwxrwxrwx 1 root root 17 21. Jan 21:49 /usr/lib/libntfs.so.10 -> libntfs.so.10.0.0
joachim-linux:/home/jre # ls -l /usr/lib/libntfs.so.10.0.0
-rwxr-xr-x 1 root root 176536 13. Jan 06:02 /usr/lib/libntfs.so.10.0.0
                
This is a  ~54 GB  Partition, my smalest one.
I'l try it from inside koppix                                  

Created attachment 193721 [details]
bziped tar of ntfsclone....

O.K., this is a 20GB HD running MS-Win this morning. It is the smalesed I could get at now.
ntsclone etc. using Knoppix 3.9b
I cannot mount using 11.0 but works under Knoppix.

It does not change after update to 11.0 A2

O.K.
I downloaded the ntfsprogs src.rpm and compiled it.
This ntfsresize works without problems.

I could not get mount.ntfs compiled.
There are bugs in the sources and mount.ntfs is disabled in the makefile.
So that I could not check.

O.K.
install of:
util-linux-2.13.0.1+git20071121-23.i586.rpm 
util-linux-debuginfo-2.13.0.1+git20071121-23.i586.rpm

doing a little bin in gdb I found:
/bin/mount searches for /sbin/mount.ntfs but it is called /sbin/mount.ntfs-3g isn't it?????
Or: where to get /sbin/mount.ntfs ?????



(gdb)
34        return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
(gdb)
453       return __xstat (_STAT_VER, __path, __statbuf);
(gdb)
638            if (stat(mountprog, &statbuf) == 0) {
(gdb) p mountprog
$25 = "/sbin/mount.ntfs\000\205\004\b`s�������?��@Q��\001\000\000\000Xs���J��@Q��Hs�\tHs�\t�\017��Hs�\t\003\000\000\000xs��7���Hs�\t\220S��pt�\t\000���pt�\t\006\000\000\000�s��\217h\005\b\006\000\000\000�s��"
(gdb) where
#0  check_special_mountprog (spec=0x9c87328 "/dev/sdb1", node=0x9c87338 "/mnt", type=0x9c87470 "ntfs", flags=0, extra_opts=0x0, status=0xbffb7574) at mount.c:638
#1  0x0804ac9c in do_mount (args=0xbffb7544, special=0xbffb7570, status=0xbffb7574) at mount.c:606
#2  0x0804c2c8 in try_mount_one (spec0=0x9c87318 "/dev/sdb1", node0=0xbffb9284 "/mnt", types0=0x0, opts0=0x0, freq=0, pass=0, bg=0, ro=0) at mount.c:743
#3  0x0804cd00 in mount_one (spec=0x9c87318 "/dev/sdb1", node=0xbffb9284 "/mnt", types=0x0, fstabopts=0x0, cmdlineopts=0x0, freq=0, pass=0) at mount.c:1464
#4  0x0804db57 in main (argc=<value optimized out>, argv=<value optimized out>) at mount.c:2067
(gdb)                                                                                              

To check:
I installed ntfsprogs-fuse-2.0.0-9.i586.rpm
and linked /sbin/mount.ntfs-fuse -> /sbin/mount.ntfs
and now I can mount my ntfs partitions as usual, but now
I have to take care for protection of /dev/sd?? to mount.
must be 666 (?)
It seems to be not optimal... but works.
/sbin/mount.ntfs-3g seems to be broken:

joachim-linux:/sbin # mount.ntfs-3g /dev/disk/by-id/ata-Maxtor_6B300S0_B6040RXH-part1 /windows/c
Failed to read $MFTMirr: Eingabe-/Ausgabefehler
Failed to mount '/dev/disk/by-id/ata-Maxtor_6B300S0_B6040RXH-part1': Eingabe-/Ausgabefehler
NTFS is either inconsistent, or you have hardware faults, or you have a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows TWICE. The usage of the /f parameter is very
important! If you have SoftRAID/FakeRAID then first you must activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for the details.
joachim-linux:/sbin # mount.ntfs-fuse /dev/disk/by-id/ata-Maxtor_6B300S0_B6040RXH-part1 /windows/c
joachim-linux:/sbin #                                                                                         

Linking mount.ntfs-fuse to mount.ntfs will work. So will using "ntfs-fuse" as the file system type in /etc/fstab (or mount -t ntfs-fuse).

Even with the FUSE mount, I still see all the requests for blocks beyond the end of the device.

The metadata clone you sent me is suspect, but that may be a result of the original file system. The image is only 3.6GB, but the file system is supposed to be 20GB? An ntfsclone -m on my system results in an image that is the same size as the original file system: 20 GB, but is a sparse file of only 140MB. 

Mine:
# ls -la ntfs.img
-rwx------ 1 root root 20972851712 Feb 19 16:13 ntfs.img
# du ntfs.img
140892  ntfs.img

Yours:
# ls -la ntfs-metadata.img
-rwx------ 1 root root 3794559488 2008-02-07 14:06 ntfs-metadata.img
# du ntfs-metadata.img
157000  ntfs-metadata.img

What does your partition table look like? Can you post the output of fdisk -l <dev> and cat /proc/partitions, as separate attachments?

I see:

joachim-linux:/ # l nt*
-rw-rw-rw- 1 root root 20974428672  7. Feb 20:06 ntfs-metadata.img
-rw-r--r-- 1 root root     2874829  7. Feb 20:24 ntfs-metadata.img.tgz
joachim-linux:/ #
joachim-linux:/ # tar tvjf ntfs-metadata.img.tgz
-rwx------ root/root 20974428672 2008-02-07 20:06 ntfs-metadata.img
joachim-linux:/ # 
joachim-linux:/ # du -sh ntfs-metadata.img
158M    ntfs-metadata.img
joachim-linux:/ # l -h ntfs-metadata.img
-rw-rw-rw- 1 root root 20G  7. Feb 20:06 ntfs-metadata.img
joachim-linux:/ # 
joachim-linux:/ # md5sum  ntfs-metadata.img.tgz
db56fe69707eda0663e7b4ebcb8098c7  ntfs-metadata.img.tgz
      
I know, there are (at least) two partition on the disk.                                                   

At the moment, the disk is not accessibel to me.
May be, there was a transmission error?
Shall I resend the file from my work PC?


                                                 

I have the same md5sum for that tgz, but the file produced is still only 3.6GB. When I tried the same thing on my local machine, with a 20 GB NTFS file system, the original image was created exactly. I don't know what the problem is.

Regarding:
>  where to get /sbin/mount.ntfs ?????

There is no /sbin/mount.ntfs because if mount does not find the a program /sbin/mount.ntfs, it tried the filesystem type ntfs with the kernel as it
does with ext2, ext3, and so on. They have no mount helper programs.

The kernel provides a (mostly) read-only NTFS filesystem which is asked to
mount then.

Your debug session from comment 5 is very helpful, the lcn field which
your gdb identifed as problem also is the problem variable in ntfs-3g.

The issue with ntfs-3g is analzed in bug 354113 - it might have the same root.

I can trigger the segfault even with an empty ntfs image created by mkfs.ntfs:

Program received signal SIGSEGV, Segmentation fault.
0xf7f29f48 in ntfs_volume_startup (dev=0x8fea0e0, flags=NTFS_MNT_RDONLY) at volume.c:403
403             if (vol->mftmirr_na->rl[0].lcn != vol->mftmirr_lcn ||
(gdb) p vol->mftmirr_na->rl[0].lcn
Cannot access memory at address 0x8

That is ntfsclone, same error.

Note: x86_64 does not reproduce the issue (like with ntfs-3g, only IA32 does).

For reproducing, the ntfsprogs i586 rpm from Factory can be installed
on a x86_64 factory system without problem.

Like with ntfs-3g, the issue could possibly be worked around with by using -O0.

Being able to resize NTFS partitions is an installation requirement for a number of installations, raising severity to blocker, medium priority.

(In reply to comment #16 from Jeff Mahoney)
> I have the same md5sum for that tgz, but the file produced is still only 3.6GB.
> When I tried the same thing on my local machine, with a 20 GB NTFS file system,
> the original image was created exactly. I don't know what the problem is.

I documented the reason in 'man ntfsclone':

 "... sadly, using the -S tar option results serious data loss since the end of  
  2004  and  the GNU tar maintainers didn't release fixed versions until 
  the present day."

The serious tar data corruption bug was fixed immediately in the CVS back in 2005 but it wasn't released in stable tar packages for at least two more years, so these archives are usually useless and not reliable (sometimes e.g. a 100+ GB file was truncated to a mere 6 bytes after untarring it :)

I think it's fairly funny that both the gcc miscompilation and the tar corruption result the same symptom ($MFTmirr reading error), so it's easy to believe one can reproduce the problem when actually it's a different one.

(In reply to comment #17 from Bernhard Kaindl)
> The issue with ntfs-3g is analzed in bug 354113 - it might have the same root.

Yes. Actually I'm fairly sure the reason is the same and related to gcc 4.3-alpha in all cases (kernel driver, ntfsprogs, and ntfs-3g).

Btw, how can I change my email address in the Novell bugzilla system (szaka@sienet.hu -> szaka@ntfs-3g.org)?

(In reply to comment #18 from Szabolcs Szakacsits)

so what about using "star" (J.Schilling)
star -sparse ...

He writes:
      If gnutar archives sparse files with more than four holes, it produces archives that violate the standard in a way that prevents other tar implementations to read
       these archives.  Star knows about that and is able to handle these gnutar archives.

(In reply to comment #20 from Joachim Reichelt)
> so what about using "star" (J.Schilling)

Irrelevant. The issue can be reproduced using mkfs.ntfs. The driver has been donwloaded 3393 times in the last three days but only those have this problem (Novell and Red Hat) who use the latest gcc 4.3-alpha compiler. 

Szabolcs, thanks for the tip. The version of the bug I was working on didn't mention the gcc corruption or that it was i386-specific. Most of my development hardware is x86_64, so I've been using that. I'm installing an openSUSE 11.0 Alpha in i386-mode now.

Or, if this has been traced to be a compiler optimization bug, should we still be chasing it as an NTFS bug besides? I guess that would explain why the original reporter was able to get things working by downloading the source RPM and building it himself.

Yes, gcc has been fix. Bug 354113 has more details.

Ok, thanks, closing as duplicate.

*** This bug has been marked as a duplicate of bug 354113 ***