Whilst Windows Live Mesh and FolderShare provide me with an effective means to keep files and folders in sync, some of my devices do not run Windows or OS X (e.g. my NetGear ReadyNAS) and I’ve been using the SyncToy v2.0 tool for data that I just want to copy from one location to another (e.g. backing the file data on the notebook PC that I use for work up to a file share).
Unlike FolderShare/Live Mesh, which automatically keep folders in sync, SyncToy is intended for performing on-demand tasks (e.g. backups), as described by Gina Trapani at Lifehacker (and by yours truly a couple of years back when it was still at v1.2).
A few days ago, I was echoing the contents of a large directory to a remote share, but was mystified by some files which would not write to the remote volume. I had full NTFS access to the files but SyncToy produced an error which said:
Error: Cannot write to the destination file. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Copying C:\Users\username\filename
After a while, I worked out that the problem files all had the read-only attribute set and that removing this allowed SyncToy to copy the files successfully. I can only assume that the problem was the echo (i.e. file copy, rather than two-way sync) and that the file attributes were being written before the file copy took place, resulting in insufficient permissions to write the file contents.
Thank you! I had the same problem, writing my backup to a samba-server. You found the solution.
Yep, I also had this same problem using a samba server under Ubuntu. It was driving me nuts! Thanks for the solution.
The error likely has nothing to do with the ‘Echo’ operation. I receive a ‘Cannot write to the destination file. Access is denied.’ error when performing a ‘Synchronization’ if the source file has the read-only attribute set even though the destination file doesn’t yet exist.
All is good when I remove the read-only attribute from the source file. It appears that SyncToy has a problem.
I had a similar problem in windows 7. Resolved now, thanks!
I had the same problem and figured out this same solution but I have a different explanation as to why it happens.
I don’t think the problem is in the files but instead in the folders.
When SyncToy echoes or syncs the folders for the first time, it first creates the folders, with the same access permissions as the original.
Result: If the origin folder is read-only, ST creates that same folder (empty) with read-only flag on the target location. So, when it later tries to copy the files over to the target folder it gets a permission error.
So, it shouldn’t be called a bug, but there could be a work-around, e.g., write the folder flags after copying the files.
This fix worked for me too. Changed the attribute “read only” by unchecking and now files are copying as they should. I also tried to run as “adminstrator” by going into the program folder and right clicking application file directly and running as adminstrator and that worked as well.