cp infloop(?) when copying a file larger than 4GiB to FAT32

[Jim Meyering]

"Jeromy Keloway" <address@hidden> wrote:
> What I have to say is a little bit... hard to believe.
> But I think I found a "bug" in the Shell-Command "cp". The command goes into 
> a endless loop when I do the following:
>
> 1) Mount a partition with the filesystem "ext3" ("/media/EXT3drive")
>
> 2) Mount a partition with the filesystem "fat32" ("/media/FAT32drive")
>
> 3) Generate a file on the ext3-System with a filesize > 4GB
>
> 4) Try to copy this file from /media/EXT3drive to /media/FAT32drive with the 
> following command: "cp -urv /media/EXT3drive/4GBfile.img 
> /media/FAT32drive/4GBfile.img"
>
> 5) The file will be transfered until the filesize reached the 4GB limit. When 
> the file has the maximum size that is possible on FAT32, it stop growing and 
> cp is waiting forever to complet this file(wait about 48h -> nothing happens).
>
>
> What cp should do:
>
> Check the filesystem on the target partition before the transfer begins and 
> inform the user about any problems OR interrupt the transfer of this file and 
> write a log/inform the user.

Thanks for the report.
However, I cannot reproduce that failure with the latest versions of cp.

  ftp://alpha.gnu.org/gnu/coreutils/coreutils-7.0.tar.gz
  ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.gz

What version are you using?
And what type of system (kernel, distro, libc) are you using?

When I try to reproduce it, I get the expected failure due to maximum
file size limitation (4GiB) imposed by FAT32; no infloop:

  # fs_type=vfat
  # mount_point_dir=mnt
  # backing_file=1
  # cd /tmp &&
    dd if=/dev/zero of="$backing_file" bs=1M count=1 seek=5000 &&
    mkdir $mount_point_dir && mkfs -t $fs_type $backing_file &&
    mount -oloop $backing_file $mount_point_dir
  # dd if=/dev/zero of=in bs=1M count=1 seek=4100
  # cp --sparse=never in mnt/
  cp: writing `mnt/in': File too large

If you actually do the above, to clean up, you'd also do this:

  rm in
  umount $mount_point_dir
  rm $backing_file
  rmdir $mount_point_dir

Then I realized that it'd be good to repeat using a non-sparse
input file, just in case the hypothetical problem is with a
non-sparse-specific code-path, so repeated and also
used the same options you used.  Same results.

Can you reproduce the problem using cp from coreutils-7.0?
If so, you can help us diagnose it by running it like this:

  strace -o log cp -urv \
    /media/EXT3drive/4GBfile.img /media/FAT32drive/4GBfile.img

Or, better still, reproduce with a stand-alone example like
the one I gave above, then we can be sure the failure is not
somehow specific to your input file.

Then post here telling where to get a copy of that big "log" file
with all the syscall trace info.
Or just compress it and attach it if it's not too large.