Karmic coreutils not compiled with large file support?

[Ethan Baldridge]

Binary package hint: coreutils

Oddly, the files in question seem to be smaller than 2 GB, so that's probably not the issue, but that's the only thing the error message seems to say.

This is copying from one external drive to another external drive.

cp: reading `sde1/foo.TIF': Value too large for defined data type
cp: reading `sde1/bar.tif': Value too large for defined data type
cp: reading `sde1/baz.TIF': Value too large for defined data type

The three files in question are less than one MB each, according to 'ls'. The external drives are mounted via "sudo mount /dev/sdd1 new_drive && sudo mount /dev/sde1 sde1" which gives me a filesystem type of "fuseblk" (rw, nosuid, nodev, allow_other, blksize=4096). I would guess that they are NTFS, but not sure how to tell for certain at the moment.

ProblemType: Bug
Architecture: i386
Date: Fri Oct 2 21:21:29 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /bin/cp
Package: coreutils 7.4-2
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
SourcePackage: coreutils
Uname: Linux 2.6.31-5-generic i686

[rogmorri (frontporsche)]

I have, perhaps, a similar issue in Karmic.

In a cifs-mounted file system, I get "Value too large for defined data type" when I try to compile a tiny program....

rsm@hina:/c/Temp/y$ ls -ld . 1.c
drwxr-xr-x 1 rsm root 0 2009-10-18 19:00 .
-rwxr-xr-x 1 rsm root 25 2009-10-18 19:00 1.c
rsm@hina:/c/Temp/y$ cat 1.c
int main() { return 0; }
rsm@hina:/c/Temp/y$ gcc-4.3 1.c
cc1: error: 1.c: Value too large for defined data type
rsm@hina:/c/Temp/y$ gcc-4.4 1.c
cc1: error: 1.c: Value too large for defined data type
rsm@hina:/c/Temp/y$ cp 1.c 2.c
rsm@hina:/c/Temp/y$

I don't see this issue in Ubuntu 9.04.

[C de-Avillez (hggdh2)]

Thank you for opening this bug and helping make Ubuntu better. This seems, indeed, related to coreutils/GNULib, but I am unsure on *where* cp could give out this error.

1. Please check, via 'mount' what FS you are running this under.
2. Also, just in case, please add here the output of 'file <blah>', where <blah> is the filenames you are trying to copy.

And we will go from there.

[Ethan Baldridge (ethan-superiordocumentservices)]

1. As I said in the bug, "mount" returned a filesystem type of "fuseblk", but the drives are formatted with NTFS.

2. I believe file <blah> returned: reading <blah>: value too large for defined data type. Attempting to access the files in almost any way returned this (rsync, cp, stat...). I no longer have the data available to me to peruse at the moment, so I cannot test this further at the moment.

[C de-Avillez (hggdh2)]

Duh. Yes, indeed, you did state it. And I missed to read, or read and missed to understand, or whatever. Sorry.

This is really weird (both your error, and rogmorri's).

[Gerhard Gessler (gerhard-gessler)]

As I am also affected by this bug, I have done a small test.

I have mounted a Windows-Share via SAMBA and copied a file with approx. 70 MB onto that mounted share. It just worked without a problem:

output of mount:
//10.0.2.2/unterrichtsmaterial on /mnt/unterrichtsmaterial type cifs (rw,mand)

copied file:
-rw-r--r-- 1 gessler gessler 82867170 2009-07-09 15:42 eclipse-cpp-galileo-linux-gtk.tar.gz

cp command:
cp eclipse-cpp-galileo-linux-gtk.tar.gz /mnt/unterrichtsmaterial/HPS/

But, if I try to compile a small C source code (e.g. the classic "Hello World") I receive the following error:
cc1: error: helloworld.c: Value too large for defined data type

compiled file:
-rwxr-xr-x 1 gessler users 76 2009-11-02 14:25 /mnt/unterrichtsmaterial/HPS/C/helloworld.c

gcc call (executed in the directory where helloworld.c is stored):
gcc -o helloworld helloworld.c

Copying a file stored in the very same directory into my HOME is also working without problem.

The system on which I have seen this bug is a 9.04 upgrade to 9.10, running in a VirtualBox environment, with all updates applied which have been released for 9.10 so far.

Please let me know if I can provide further information / do some tests in order to fix this bug.

[rogmorri (frontporsche)]

btw, I had entered the gcc error as bug 455122

[Steffen Neumann (sneumann)]

Hi,

we're hunting down a similar problem on an i386 karmic with a remote CIFS filesystem.
The problem does not appear on a amd64 karmic installation, and not with the older 2.6.28 kernel.

Gerhard: Can you reproduce the problem even without gcc using simply

      /usr/bin/stat helloworld.c

Yours,
Steffen

[Gerhard Gessler (gerhard-gessler)]

Dear Steffen,

sorry, but without gcc being involved, there is not problem recognizable (at least for me):

/usr/bin/stat on the file helloworld, located on an ext3 partition:
  File: „helloworld.c“
  Size: 76 Blocks: 8 IO Block: 4096 reguläre Datei
Device: 811h/2065d Inode: 58024 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ gessler) Gid: ( 1000/ gessler)
Access: 2009-11-18 08:27:22.000000000 +0100
Modify: 2009-10-30 09:26:54.000000000 +0100
Change: 2009-10-30 09:26:54.000000000 +0100

/usr/bin/stat on the file helloworld, mounted via CIFS:
File: „/mnt/unterrichtsmaterial/HPS/C/helloworld.c“
  Size: 76 Blocks: 32 IO Block: 16384 reguläre Datei
Device: 17h/23d Inode: 29718476512 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ gessler) Gid: ( 100/ users)
Access: 2009-11-02 00:00:00.000000000 +0100
Modify: 2009-11-02 14:25:22.000000000 +0100
Change: 1940-10-24 04:26:18.955161600 +0200

According to /proc/version is the running kernel:
Linux version 2.6.31-14-generic (buildd@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009

The system has all updates applied which have been available so far for karmic.

Hope this helps,

   Gerhard

[Gerhard Gessler (gerhard-gessler)]

Hi all,

adding the option "noserverinfo" to my call of mount.cifs cured the problem for me. I found this workaround described in

https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/455122
and
https://bugs.launchpad.net/ubuntu/karmic/+source/linux/+bug/406466

Cheers,

   Gerhard

[Ethan Baldridge (ethan-superiordocumentservices)]

Unfortunately, "noserverinfo" isn't an option for mounting NTFS. :(

[icetnet (bfetters)]

the "noserverinfo" option does work, even if it is not contained in the documentation... like so.

sudo mount -t cifs -o username=domain/user,password=password,dir_mode=0777,file_mode=0777,noserverinfo //ip.ad.dr.ess/share /mountpoint

Good luck.

[astrotom (t-rauscher)]

Seem to have the same problem as described in the original bug report. Installed fresh kubuntu 9.10 64 bit on new PC, did all the updates.
output of uname -a:
Linux *** 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux
(I replaced my machine name with *** here). I have two identical hard disks configured as RAID 1, with / on device md0 and /home on device md1. md0 and md1 are formatted with ext4.

Then I attached an external hard disk via USB. The external harddisk is formatted as NTFS. mount shows this as
/dev/sdg2 on /media/Mr. Big type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)

Using cp -a I wanted to copy the contents of the external disk to a directory /home/backup (which I had created beforehand). Almost all of the files got copied, their size varying from a few kB to several GB. There were problems with three files:

cp: Lesen von „/media/Mr. Big/file1“: Value too large for defined data type
cp: Lesen von „/media/Mr. Big/tmp/file2.vob“: Input/output error
cp: Lesen von „/media/Mr. Big/tmp/Import_DVD/file3.MPG“: Value too large for defined data type

(sorry, I have a german system, "Lesen von" means "Reading". Interestingly, the actual error message shows up in English as shown above.)

The info on the three files:
file1 has 3.4 MB, error occurs after 2.7 MB have been copied, output of file file1:
Non-ISO extended-ASCII mail text, with very long lines, with CRLF line terminators

file2.vob has 3.5GB, copying stops with error after 2.3GB have been copied; output of file file2.vob:
MPEG sequence, v2, program multiplex

file3.MPG has 1.9GB, error occurs after 886MB have been copied, output of file file3.MPG:
MPEG sequence, v2, program multiplex

It seems to me this is not really a problem with large files as several other large files (for example one with 8.4GB and one with 4.0GB) got copied ok and my file1 is quite small. Perhaps it is a problem with fuseblk accessing NTFS volumes. or with the USB? Perhaps I should try to take the external disk out of its case and use it as internal disk, mount it as NTFS and see whether the error still occurs. (ah, I just realize I cannot do that; the external disk is an internal IDE disk mounted in a case, my new PC has SATA interfaces... well, I'm not sure if I want to buy a converter just to check this.)

[Launchpad Janitor (janitor)]

[Expired for coreutils (Ubuntu) because there has been no activity for 60 days.]