LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Fatal error: File too large. (https://www.linuxquestions.org/questions/linux-general-1/fatal-error-file-too-large-428919/)

can564 03-27-2006 05:43 AM

Fatal error: File too large.
 
I am try to save a 20gig fat32 partition off of a failing hard drive.I have used dd_rescue to save an image of it.I would now like to repair the image file.

I am using Fedora Core4 on a 160gig drive and have put the image file in my root home and I am working with it there.I have used fsck.vfat and g-part to try and repair it.Both error out with the following.

[root@localhost ~]# fsck.vfat ryan2.img
dosfsck 2.10, 22 Sep 2003, FAT32, LFN
open ryan2.img:File too large

[root@localhost ~]# gpart -g ryan2.img
*** Fatal error: open(ryan2.img): File too large.

I have tried googling for examples of file to large.I cannot seem to find a situation similiar to mine.I assume it is one of two things.
1)Fedora Core4 can not handle large files
or
2)the image file is too damaged to fix.

Could anyone steer me in the right direction?

ethics 03-27-2006 06:38 AM

what format is yoru FC partition in, googling the file size limit for ext3 gave me

Quote:

Originally Posted by Some mailing list post on Google
]If you are using a 1k filesystem, then a file can consist of ten
direct blocks, plus 256 data blocks addressed via the indirect block,
plus 256*256 data blocks addressed from the indirect block, plus
256*256*256 data blocks from the triple-indirect block:

(10 + 256 + 256*256 + 256*256*256) * 1024 = 17247252480

Does that number look familiar? So the problem is that you created
the file system using a 1k blocksize. Filesystems with a 1k blocksize
are horribly inefficient for large files, and they max out at a little
over a little over 16 gigabytes. (Note that 16 gigs is 17179869184
bytes, unless you are a disk drive company in which case your
marketing department calls it 17 gigs. :-)

Although i found another saying the 2.6 kernel with Ext3 on a 32 bit will support upto 1TB file size, maybe dd isn't using large file support in userland? ( i have no idea what that means but the same guy as above posted it too:

Quote:

Originally Posted by same random mailing list post
Your utility is the
culprit most likely, because 32-bit applications must implement large
file support in userspace in order to handle files above 2 GB in size

(The above are from an FC2 Mailing list BTW so might be out of date)

maybe that's your problem? I don't have a clue just thought i'd research it :)

Good Luck

can564 03-27-2006 07:06 PM

I'm going to have to look into that.I thought I would have a chance tonight and have not.Let me dig into that and I will post back here.

can564 03-28-2006 06:25 AM

OK I was able to get back at it.My Fedora Core4 is a ext3 format.My file image is about 19gig.I did some digging and it was brought up that I probably have to mount to the image to run fsck or gparted.Otherwise they only see the single file/image.I did have time to try and mount it but errored out.This is what I tried.

Quote:

[root@localhost ~]# mount -t vfat -o loop /root/ryan2.img /mnt/rysave
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

[root@localhost ~]# dmesg | tail
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03e6820(lo)
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
ISO 9660 Extensions: Microsoft Joliet Level 1
ISOFS: changing to secondary root
application mixer_applet2 uses obsolete OSS audio interface
loop: loaded (max 8 devices)
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev loop1.
[root@localhost ~]#
Back to the drawing board.


All times are GMT -5. The time now is 03:20 AM.