"Jeromy Keloway" <[email protected]> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
