Re: File::Copy::Recursive::dircopy failing without error in $!

You should closely inspect the security settings of D:\Eterra\Distribution\XXXCorpXXX\bitmaps in Windows explorer. I could reproduce the behaviour (no files are copied, no content in $!) by denying write access for the destination file. These Windows DENY permissions can not be modified with chmod and they are not visible to any checks made by File::Copy::Recursive. On Windows, the copy operation eventually calls Win32::CopyFile which does not set $! in that case.

There may be other relevant settings in a Windows environment which I did not test. For example, chmod does only change the user's permission, the "group" and "others" parts are ignored.

A minor note: When you call clear_readonly_bit($destination); please be aware that this does not remove any readonly bit of $destination itself. This can bite you if $source and $destination are both files and not directories.

Comment on Re: File::Copy::Recursive::dircopy failing without error in $! Select or Download Code

Replies are listed 'Best First'.
Re^2: File::Copy::Recursive::dircopy failing without error in $! by Lotus1 (Vicar) on Jun 13, 2018 at 19:04 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: File::Copy::Recursive::dircopy failing without error in $!
by Lotus1 (Vicar) on Jun 13, 2018 at 19:04 UTC

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.

[reply]
[d/l]
[select]