# [FreeNAS] Never-ending copy (cp) causing a file to grow in size?



## scifury (Jan 17, 2011)

So I'm experiencing a strange problem with the CP command.  When I try to copy a folder containing five WMV video files from an NTFS-formatted external USB drive to an internal UFS-formatted internal SATA drive, the copy process gets stuck on one of the files, approximately 150mb in size.  What happens is the file keeps copying, and copying, and copying, all the while getting bigger, bigger and bigger in size.

The command I'm using is: [cmd=]cp -R "/mnt/Backup/Videos/" "/mnt/Data/Videos/"[/cmd]

After several minutes, the file balloons to dozens, than hundreds of gigabytes, which will not stop until I terminate the login. This seems incredibly bizarre.  Is there any possible explanation, perhaps related to NTFS support, or something else?

I'm using the minimal version of FreeBSD 7.2 in FreeNAS, the network-attached server software.


Appreciate any theories,

- David


----------



## SirDice (Jan 17, 2011)

Sounds like the file itself is corrupt. It's fairly easy to create a file that loops back onto itself. 

Have you tried running chkdsk from a Windows machine on that disk?


----------



## scifury (Jan 17, 2011)

I ran a chkdisk within windows XP on the ntfs drive, tried copying the directory again and no endless loop!  Wish Windows XP would have been kind enough to provide a chkdisk log to see what changes it made, but at least it works.

Thanks, simple solution.  The looping copy behavior is still unsettling, corrupt file or not.  It would be nice if there were automatic safeguards against that, such as the command terminating on its on own.


----------



## phoenix (Jan 17, 2011)

cp does terminate on its own, once it receives the EOF (end-of-file) signal.  However, if the file is corrupt, and just keeps looping through the same data, cp never gets to EOF.  There's really nothing you can do, unless you want to get into the hairy "exactly how many bits/bytes is the source file, stop copying after that many bites/byes" situation.  It's hairy in that the source file may be in a compressed filesystem, so you can't just look at the "size on disk".  And it may be in a filesystem with dedupe enabled, so even "apparent" size doesn't help.

It's nowhere near as simple as issue as you think.


----------



## SirDice (Jan 18, 2011)

phoenix said:
			
		

> It's hairy in that the source file may be in a compressed filesystem, so you can't just look at the "size on disk".  And it may be in a filesystem with dedupe enabled, so even "apparent" size doesn't help.


Don't forget sparse files


----------

