Unable to copy/delete ... Access is denied?

[Aaron]

Hello Andrew,

To clarify, you performed the copy on a file pair that was reproducibly throwing the error in BC3? The test workflow I am hoping to check:
1) Attempt the copy and hit an error
2) Re-attempt the copy on a single file that threw the error when attempting to overwrite the other side. Perhaps try it two or three times in a row to make sure it is sticking.
3) Immediately open up Explorer and perform the copy of that file from the same source, to the same destination and attempt the overwrite.

[andrew_t]

Yes, that is correct. The problem was occurring persistently in BC3 with this one file being copied to this specific destination - even after trying repeatedly in BC3, restarting BC3 and restarting both of the computers in question. I verified again that BC3 would not copy the file before going into Explorer (using the contextual menu) and copying it there, which succeeded without any problems.

[andrew_t]

Perhaps the "Access is denied" message is a red herring.

I just had (reproducible, persistent) errors trying to update/copy in BOTH directions with my Mac (mounted as a network volume on M: ), but they report different errors. (See attached screenshots.)

Copying TO the Mac leads to the "Access is denied" error I have previously described.

Copying FROM the Mac causes BC3 to report "The filename, directory name, or volume label syntax is incorrect".

I was able to successfully copy the files in both directions using Explorer, no errors were reported.

[Aaron]

Hello,

Where does M:\Documents bind to on your Mac system? Did you use the built-in Preferences to share it? http://support.apple.com/kb/HT1549

[andrew_t]

M: points to \\MINI\andrew, the user folder which is automatically shared; it is not separately configured in the Preferences Panel for Sharing. SMB sharing is enabled for the user "andrew", who has the same password on the Laptop (\\HAMBURG) and on the Mac (\\MINI). (M: accesses the share \\MINI\andrew with saved credentials for the user MINI\andrew.)

For the purposes of testing, I tried setting up a separate share for the "Uni" folder and doing a new folder compare between C:\Users\andrew\Documents\Uni and \\MINI\Uni. This did not fix anything.

[andrew_t]

I am continuing to have this problem with great frequency when using BC3 to copy directly over the network between Win7 and my Mac Mini. Have you been able to determine anything further about it or can you suggest other things to try?

I have come up with a temporary, if very unsatisfactory workaround that involves mounting the PC folders via the network on my Mac, then running BC3 under XP in a virtual machine (using VirtualBox). Updates and copies that are not possible from BC3 on the Win7 machine proceed here without difficulty (just as they do in Windows Explorer and in the Mac Finder), but I have to go back through and "touch" every copied file thereafter, since this roundabout way of getting it to work seems to mess up the timestamps.

[andrew_t]

I continue to have the problem as I previously described it, but I realised at some point that it only seems to affect .doc files. The solution has thus been to open the offending files in Word and then save them as (XML-based) .docx files.

I don't know if the voodoo (data corruption?) goes away simply because the file has been saved as a fresh one or if it is the XML-based format that somehow makes the difference. In any case, I have so far never had problems copying .docx files.

[Aaron]

Hello,

I've only recently added a Mac Mini to my testing hardware suite. It currently runs 1.8.3, and I enabled sharing in a similar method as you described (Sharing Settings, enabling Samba, and my similarly named user).

Unfortunately, I'm not seeing the same issues you are running into. The sync seems to work as expected between Windows 7 and the Mini. I also noticed in an earlier screenshot that at least one .docx file was included in your error list. I would guess that it isn't doc vs. docx that is the problem, but once you hit the issue something gets cached and converting the file gets avoids this.

Are you still running a version of OSX 10.7? Are you testing with the latest BC 3.3.7?

Are there any other pointers you can think of to help replicate the environment of your sync?