Syncback is unable to copy files, which are not already held open, and are owned by the current user.
Posted on 2011-03-09
This is a weird problem, haven't been able to solve it, and need guidance on what to try or look into next.
The original symptom is that two files, which are excel spreadsheets, would not be backed up from the source to the destination.
Here's what I know so far:
The files are not being held open. Used Process Explorer, and individually checked all processes which might relate to holding the files open (could not find how to do a find for a specific part of the filename). Used openfiles on the command line, and it also showed no files were held open (could this be right, or be limited to the current user only and not systemwide)
I've found that the files /can/ be copied after copying the parent folder to another name. The files in the "- Copy" folder copy fine.
Renaming the original folder to a different name will allow the files to be backed up fine.
Switching the folder names (orig -> orig.bak, orig.copy -> orig, orig.bak -> orig.copy) will cause the file in the originally named folder to /NOT/ be copied.
From what I can tell so far, there is a "negative affinity" between these two filenames and syncback.
I've searched on the web for other occurrences of this, found some, and they seem to relate to a registry problem. Note this is a newly installed (about 1 week ago) Windows 7 Pro 32 bit.
Any thoughts on how to learn more about what might be causing or fixing this?
Thanks in advance for your help!