Moving a project while it is open can indeed make for a bit of a mess[size=80][1][/size]. Scrivener has no way of knowing what you did, or where the project went, so it goes on ignorantly using the old location to write only those files that have changed after the project was moved.
To provide a very much simplified example, say you have a folder with two files in it, “A” and “B”, and you’re using something that makes use of both of those files (like Scrivener). You move the folder with “B” open in this program. Both “A” and “B” (in its current state which may not be saved yet) will be moved to the new location, but the program goes on using the old location, saving “B” where it expects it should be saved. The end result is that you have a “B” file over in the old location that is newer than the “B” file in the new location. To fix the problem then, the solution is simply to move “B” to the new location itself, overwriting the old version.
With Scrivener there are many more files than that, and subfolders as well, inside of the project on your disk. So merging the changed copies with the old one may be a bit of a chore and an exercise in trial and error until everything is glued back up the way it should be.
What might be a far superior solution to the problem is to set both of these copies aside, the one you moved and the one with the bits of stuff that got left over in the old location (the “B” file in our example) and roll back to an earlier backup made prior to the attempted move. If you’ve never restored from a backup before, there are instructions in the user manual, under §7.11.4, Restoring from Backups, starting bottom of pg. 69.
In a worst case scenario, say you have no recent backups because the project was too huge to back it up regularly, it should be possible to glue things together like I described. You’ll just be working with modification dates and copying files over from one place to the other in their proper locations (for example if you find a file called 22.rtf in the project’s Files/Docs sub-folder, you would drag that newer copy from the old location to the same sub-folder in the new location. To investigate the internal files and sub-folders of a project in Finder, right-click on them and select Show Package Contents from the contextual menu. I would highly recommend duplicating both the original project you moved, and the fragmented project, so that if things go wrong you can go back to at least how they were at this point and try again.
Let me know if you what you see isn’t like what I describe. As I mentioned in the footnote, I cannot actually test these conditions on my current working computer as it doesn’t fragment to begin with.
Notes:[size=80]
- At least in older versions of Mac OS X. I just ran a quick test to double-check my facts here and found that in 10.11 “El Capitan” if I move an open project the software stays in sync. So it could be the newer operating systems are doing a better job of letting software know when their files have changed names or locations.
[/size]
