Syncback is unable to copy files, which are not already held open, and are owned by the current user.
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!
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!
Asked:
Who is Participating?
Can you provide the full paths to the files? If they are over 256 characters in length, SOME programs might not be able to handle that.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
(Make sure to use it's filtering to only show errors related to your process - it produces a lot of data).
Also, have you run chkdsk on that drive?