GNOME Bugzilla – Bug 340320
tib backup files produced by Acronis True Image Home are zeroed
Last modified: 2008-03-26 17:19:40 UTC
Please describe the problem: I use Acronis TI9 Home to make full disk backups in dvd sized chunks (tib files). I have two WD 160Gb hard drives and a WD 320Gb firewire connected backup drive. I backup the harddrives to folders hda & hdb on the first partition (sda1 vfat), and I make a safety backup of hda to a folder hda-tibs on the D drive (hdb). A backup image consists of between 3 and 5 tib files. A week ago all EXCEPT the last tib file in each image set were zeroed! I should mention that besides XP Home, I have 3 Gentoo copies, a Kanotix- and a Slax-poormans install to hdb, and a Wolvix LiveCD saving changes to hdb. The problem occurred again yesterday, and again today after I activated Gparted in Wolvix. Finally this evening, simply by using the latest Gparted LiveCD.. Steps to reproduce: 1. Run up the LiveCD, I used Vesa driver 16 bit, 'no' keyboard, US English. 2. Gparted couldn't find any disks, so I rebooted into Gentoo 3. Checked sda1 - zeroed tib files on sda1 AND hdb10 (D drive) Actual results: Well, until today I have had little success getting to a desktop with earlier versions of your LiveCD. Today I got there saw the GUI, but the progress bar went back & forth looking for disks. Didn't find any.. see 2 and 3 above. Expected results: I would expect the usual Gparted screen to show my disk status at least. Does this happen every time? It takes me a few hours to backup both drives so I haven't tried it again yet but I will by tomorrow afternoon. Other information: a) None of my other files have been affected. b) A bunch of fsck000x.rec files are produced when the files are zeroed.
my post to the Acronis TI Forum about Gparted is at http://tinyurl.com/ljayn
OK, a) I backed hda up again twice, to /sda1/hda and to /sda/hda/down (vfat) b)I backed hdb up again to /sda1/hdb (vfat) in 5+ dvd-size chunks c)I backed hda up again to /hdb10/hda-tibs (vfat) in 3x dvd-size chunks and renamed the files by dropping the tib extension. d)I backed hdb up to /hda1/hdb-tibs (ntfs) as one large 33GB file and renamed the file by dropping the tib extension. I booted Gentoo (Linux p4pe 2.6.17-rc3 #1 Sun Apr 30 14:15:25 CEST 2006 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz GNU/Linux) updated to gparted-0.2.4 and parted-1.6.25, activated Gparted and the tib files were immediately zeroed out, except the last one in each image set! The tib files which had been renamed by dropping the tib extension were untouched... :-D
So is this a LiveCD problem or a GParted problem? In plain english can you explain what needs to be fixed on the "livecd".
This is a Gparted problem with Acronis tib files on vfat partitions. I have just converted the sda1 vfat partition to ntfs, made a 32GB backup to it consisting of 7+ tib files, booted the same Gentoo copy as above, checked the tib files were OK still, ran Gparted and the files are still OK. So, this very weird problem is with Acronis TI tib files, on vfat partitions, and Gparted both from Gentoo, Wolvix, and your LiveCD. Sorry about pointing this at the LiveCD, its failure merely confirmed the problem seen using Wolvix Gparted, and the Gentoo failure re-confirmed both. I can't say whats wrong with the LiveCD, but I'll stick with Wolvix for a Gparted LiveCD for now..
If you want to confirm it, a trial version of Acronis TI Home is available here http://tinyurl.com/4z34y
Have been doing further tests and found the Gparted CD to be the best tool to show the problem. Since converting my firewire tib folder sda1 to ntfs the tib images there have stayed OK. I just ran Gparted CD and on reaching the display, both vfat partitions (hdb10 and sda5) containing tib files were shown with Warning indicators: "Unable to read the contents of the filesystem. Because of this some operations may be unavailable. Did you install the correct plugin?" A third vfat partition with no tib files, displayed OK. I rebooted Gparted CD, and now the the warnings had gone - no doubt because the tib files had been 'neutralized'.. I rebooted to XP & sure enough the tib files had been zeroed. Btw. It would be nice if the LiveCD had a filemanager.
I have just made a Slax Popcorn CD containing the Gparted 0.2.4 module. This boots straight up into Xfce with no interactive questions, and one can choose Gparted from the System menu. This started OK, and immediately indicated the warning icon for the sda5 vfat partition containing Acronis tib files. Opening Xfce file manager, one could see the first two tibs of three had been zeroed. Unlike the earlier test above, tib files in hdb10/hda (vfat) were untouched.. I have btw left a request on the Acronis True Image forum for a linux user to confirm these results.
Just to bring this up to date, I downloaded 0.25 LiveCD and confirmed that yes it still zeroed tib files.
An update with my recent findings.. I am now using True Image 9 Home Edition build 3633. As Gparted was updated recently to 0.25, I checked out backup of my disk0 to a vfat partition on a 320GB firewire drive, using my usual split-size of 4.34GB, and it failed exactly as before. All tibs were zeroed, except the last 1.5GB one. I should perhaps have reacted earlier to the question of file size, because the last tib in an image was always OK! Anyway, never too late to learn ;-) I retried backup selecting the CD-size split (716.8 MB), which resulted in 14x tib files, ran Gparted-0.25 again, and they were all OK! Then it was a matter of trying to find the largest split-size which worked - I found that using 3.9GB (4,089,446KB) is OK, while 4.2GB isn't. Hopefully this information is of use to someone. NB! A response on the Acronis forum was "The maximum file size for FAT32 is 4GB minus 2 bytes" but as I pointed out, "I have no problem using & restoring from 4.34GB split images backed up to fat32 partitions, only when using Gparted" Comments would be appreciated
It appears that the problem with Acronis files being "zeroed" is related to the dosfsck command contained in dosfstools. The package dosfstools includes the commands mkdosfs (mkfs.dos) and dosfsck (fsck.msdos). The command mkdosfs is used to create a new FAT16 or FAT32 file system, and dosfsck is used to check and correct errors in FAT16 or FAT32 file systems. The dosfstools package is used by many GNU/Linux distributions (including the currently unsupported GParted LiveCD), and by the GParted program. Many GNU/Linux distributions use the dosfsck command on boot up to ensure that all FAT file systems are healthy. The GParted program uses the dosfsck command only after operations such as Move/Resize have been chosen for a FAT file system, and Apply operations has been selected. For instance, dosfsck is used prior to operations (e.g., move/resize) on FAT file systems, and also after the operation to ensure that the FAT file system is healthy. If no operations are selected on FAT file systems, then the GParted program does _not_ run dosfsck. From a quick search on Google, it would appear that there is no obvious maintainer for dosfstools. Some GNU/Linux distribution distributions, such as Ubuntu, appear to be maintaining their own patches for dosfstools. The problem discussed under this bug topic appears to have been reported to the Ubuntu team. See: https://bugs.launchpad.net/ubuntu/+sour … +bug/62831
Hmm... the above URL is now incorrect. I will try posting it again. https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/62831
This is a bug in dosfstools. The Ubuntu team patched this problem and listed the following comment: dosfstools (2.11-2.1ubuntu2) feisty; urgency=low * Fix some integer overflows in check.c and fat.c which resulted in large files (close to 32-bit limit) being errorenously truncated to 0 bytes. Closes LP#62831. -- Stefan Potyra <email address hidden> Tue, 19 Dec 2006 02:21:45 +0100 A patched version of dosfstools is available in the Ubuntu repository at: https://launchpad.net/ubuntu/+source/dosfstools