Do you know where your variables are? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I found that the file that could not be copied over, the one at the destination, was owned by the local Administrators while other files in the same folder were owned by SYSTEM. I changed it to SYSTEM to match and the problem went away. I don't understand this since both have full control access to the file. Setting it back to Admins didn't cause the problem to reappear. This issue might have been cleared by something else I did to the security settings without realizing while investigating. I was able to duplicate what you described with the DENY write access setting. Your observation about my clear_readonly_bit() function was a good one. In this case I'm always copying folders but I wanted to set it up in case someone else puts a file in the list to copy. Thanks! Update: I found if I set $File::Copy::Recursive::RMTrgFil to true it will delete the target file first even if it has the deny setting. I don't want to do this all the time since normally only a few files will change or be added. But I can use this in the case where there is a copy error to retry by setting $File::Copy::Recursive::RMTrgFil true locally. In reply to Re^2: File::Copy::Recursive::dircopy failing without error in $!
by Lotus1
|
|