Problem with copy() in perl (5.6.0)

This is possibly not the right group - my first post to qdn.public…

I am using a set of perl scripts to build modules for our qnx box. A
couple modules fail the build because I get an ‘unknown’ error from Perl’s
copy() function when it tries to copy these modules to another location. I
am using the File::Copy package and Perl 5.6.0.

The script build over 20 modules, but consistently fails to copy the same
two modules - all others are fine. These two modules are library modules
so no special files

Instead of using copy() I used the system command with cp here I got error
code 256.

Anyhow, this has got me puzzled. Can anyone shed light…


Thanks,


Hanif.

hladha@vortek.com wrote:

This is possibly not the right group - my first post to qdn.public…

I am using a set of perl scripts to build modules for our qnx box. A
couple modules fail the build because I get an ‘unknown’ error from Perl’s
copy() function when it tries to copy these modules to another location. I
am using the File::Copy package and Perl 5.6.0.

Hm… I don’t know much about Perl, so I really don’t know what the
unknown error means – if it were C, that would be an errno the library
decoding errno’s doesn’t recognise.

The script build over 20 modules, but consistently fails to copy the same
two modules - all others are fine. These two modules are library modules
so no special files

Simple libraries, or shared objects? (.so extension)?

What are the actual source & destination strings?

If you try a manual cp of the files, what happens? What if you do the
manual cp of the files with the -v option, what does it say?

What type of filesystem is the target file system? Normal disk,
DOS, Flash, something else?

Instead of using copy() I used the system command with cp here I got error
code 256.

The return from the C library system() is a exit status, to be looked at
using the WIFEXITED() and WEXITSTATUS() macros from <sys/wait.h>. 256
happens to be exited, returned 1. This means cp failed, but cp doesn’t
return much more information in its exit status – though usually if
something has gone wrong, it will spit out a text message as to what
did go wrong.

Anyhow, this has got me puzzled. Can anyone shed light…

No direct light…but maybe some ideas as to how to shine the flashlight
closer to the object that is hiding…

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> writes:

Simple libraries, or shared objects? (.so extension)?

What are the actual source & destination strings?

If you try a manual cp of the files, what happens? What if you do the
manual cp of the files with the -v option, what does it say?

What type of filesystem is the target file system? Normal disk,
DOS, Flash, something else?

The strings are as follows:

$srcfile="/home/hladha/work/rtp/transfpolinom/lib/transfpolinom.so";
$destree="/nt/swdev/ReleasedUnits/rtp/transfpolinom/R1.00/lib/qnx6";

and my copy statement is

if (!copy($srcfile, $desttree))

Note: the above strings are generated at run-time based on the modules, version number, etc.

I am copying a shared library (just like the other modules). Yes, I am
copying across a mount point (using /usr/sbin/fs-cifs command).

I also pointer my $destree to a local dir on the qnx box. Alas same problem.

I am able to use the shell and perform the cp command. I did get an error
about setting the file mode - but the data was copied. If I use cp -t then
the mode error was gone.

Both the filesystem reside on normal drives.

The latest is that if just write a couple of lines of stand-alone perl that
just takes the above two strings and does the copy then it work!! So I
guess the problem is now in my build scripts - somehow I have lock on the
source file, etc…

Will keep hunting.

Hanif.