use strict;
use warnings;
use File::Copy;

my $source="C:\\sandboxes\\source_backup\\source_backup\\source_develo
+p\\source_folder\\source_part\\source_specific\\source_common\\rb_src
+c_sourcedevelopfolderpartspe_Interfacessourcecommonspecific.h";
my $target="C:\\sandboxes\\target_backup\\target_backup\\target_develo
+p\\generated\\_hnv_scan\\_source_develop\\source_folder\\source_part\
+\source_specific\\source_common";

print "OK 1\n" if -e $source;
print "OK 2\n" if -d $target;
copy($source,$target) or die "could not do: $!";
print ("done");
[download]

C:\_32\pscrpt>perl try.pl
OK 1
OK 2
done
C:\_32\pscrpt>
[download]

C:\_32\pscrpt>perl try.pl
OK 1
could not do:  at try.pl line 10.
[download]

What error are you getting? You could be hitting some OS (which?) based path depth limit. Let perl tell you what happened:

copy( $source, $target ) or die "couldn't copy file $!";
[download]

Good advice. I'd include the paths too as the longer they are the more likely it is that one of them may have a typo.

copy( $source, $target ) or die "couldn't copy file '$source' to '$tar
+get': $!";
[download]

the other files in that folder are copied but not this, if I reduce the name of the file then it works but that is not possible for me.

"could not do at C:\sandboxes\Scripts\dummy.pl line 9" the error I got. any other solution? or can I copy the folders, sub folders and files in line of code? I'm using Windows

Which version of Windows? It doesn't look like you tried what I suggested, note the $!

copy( $source, $target ) or die "couldn't copy file $!";

#---------------------------------------------------^
[download]

Hi,

Did you try the copy outside your Perl program on the command line, cutting and pasting the pathnames from your code? I see that when you printed the error it stated that the file or path does not exist.

Hope this helps!

the path name was mentioned also in the line 9

The part of the filename that says:

so­urce_specific
-><---
[download]

The HTML says:

<font color="red"><b><u><wbr>­</u></b></font>
[download]

I'm not sure if that is an artifact of the way this site renders the code .. but there appears to be a problem with what it contains.

I don't see anything like that in the post, so it must be how this site renders the code for you. Check Code Wrapping in your Display Settings.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Thank you for pointing that out -- Yes - it does appear to have something to do with local rendering.

My setting has "Code Wrap Length" set to 100 , and "Auto Code Wrapping" enabled.

The inserted HTML starts at the 104'th character, so it is likely that some characters (probably backslashes \\) do not count.

The inserted HTML does have a clue that it has to do with wrapping:


<font color="red"><b><u><wbr>­</u></b></font>
[download]

I learned that:

The <wbr> (Word Break Opportunity) tag specifies where in a text it would be ok to add a line-break.

                "Imaginary friends are a sign of a mental disorder if they cause distress, including antisocial behavior. Religion frequently meets that description"

Your problem is almost certainly Windows. You will need to work around some Microsoft dain bramage by changing to the source directory, opening the source file using a relative filename, changing to the target directory, opening the target file using a relative filename, and then copying the file contents. Note that you may have to change directories in steps (chdir('C:\sandboxes\source_backup\source_backup\source_develop') && chdir('.\source_folder\source_part\source_specific') && chdir('.\source_common') or die "chdir: $!"; is one possibility) if the directories are themselves deeply nested with long names, or use UNC paths for source and target, which are either exempt from path length limits or have higher limits — I do not know which.

Your problem is almost certainly Windows

I think the problem is almost certainly a typo - but only because, having replicated the OP's file structure (as specified by his code), I can find no problem with it on Windows 7.
OP's script works fine for me, as is.

Either way, it would be interesting to know precisely which it is, but I'm not confident that we'll find out.

Cheers,
Rob

The example paths in OP's code look sanitized to me and I suspect that the real file names are much longer. I have had these kinds of errors occur at $WORK with mapped network drives in the past and the solution I used then was to simply map another drive letter to a subfolder and access the deeply nested directories that way.