I am running a perl script on a new (well, the disks are new)
PC running Slack 10.2 2.6.13. This perl script has been running for over 5 years now on other machines and in fact is also running fine on a Suse 9.3 (2.6.11) machine with the same hardware.

The script says at some point:
my $from=$avfiles{$office_version}. $fileread;
my $to=$doneavfiles{$office_version} .$fileread;
#my $to=$fileread;
my $rc1= 0xffff & system ("cp $from $to");
unless ($rc1==0){print "$fileread copy from AVFILES to DONEAVFILES failed. Maybe took too long?";
sleep 2; #and if it still has not been copied, then...
die "not copied ( cp $from $to ) ! $fileread\n" unless (-e "$to") ;
}#unless rc1==0
##################
which is a simple system call to copy a file,
there is plenty of space left in the disk, but on the Slack system this is erratic, i.e. sometimes the cp fails
I checked the /var/log/messages and there is no hint of something gone wrong. Permissions is not an issue(both directories are 777) , disk space is not an issue, so what could trigger the failure? These are medium-size files, some 70k at most.


calling system cp
not copied ( cp /home/myusr/AVFILES/200512231230.s7nymsc1.0.2.av.gz /home/myusr/DONEAVFILES/200512231230.s7nymsc1.0.2.av.gz ) ! 200512231230.s7nymsc1.0.2.av.gz
200512231230.s7nymsc1.0.2.av.gz copy from AVFILES to DONEAVFILES failed. Maybe took too long?

P.S. I guess I should check(and I will) the rc1 return value..., just need a
general update on what could go wrong with cp if space and
permissions is NOT an issue.

Checking the return value is top priority. The O'Reilly "Camel book" gives good examples of how to check a return value from system(). cp will also fail if the source file is non-existant for some reason. Your script doesn't indicate how the source file was generated. Maybe it's creation step failed previously? Without knowing what return value you're getting, you can't tell if it's a problem that cp is having, or a problem that the shell is having invoking cp (like a bad PATH or something).