A third reason is that the user can change the Binder title of a document, but Scrivener needs to understand that it’s the same file in order to make sure bookmarks and other cross references continue to work.
2 Likes
A possible un-stated but fourth reason – to discourage writers from meddling with the files inside the *.scriv folder/package.
3 Likes
Yes, it was.
I already did, the same with the prior version, thank you.
OK, yes, but I could not understand why this explains that a combination of UUID characters and the user title should not work. “deliberately give multiple documents the same name”: well, well, then just show an error message like usual in Windows, I would think. And “chararacters that are not allowed” could be replaced by allowed characters, a common method, I would think.
But, I guess, it wouldn’t help getting back the project anyway. Maybe it would be good to get rid of that issue / bug (wouldn’t help either now, I am afraid). I cannot even understand why an issue or bug can occur at all, that has apparently existed for a long time, which makes the entire project totally unusable (including its backups).
Yes, and discourage them from reconstructing, thank you for stating that unstated fourth reason, good to know. It might also be useful to discourage writers from meddling with the files in the installation folder or just from deleting them, to avoid Scrivener suddenly stopping to work. But of course, this can also be handled through issues / bugs. In that case, deleting would not matter. But of course, the developers know best how to proceed here.
Stated often here in the forum, and just makes good sense, actually. Sorry for your trouble.
1 Like
I had a problem once. I found two very old versions of a project that I had not touched for a while. I din’t know which one was “the current one”. I ended up coming with a semi-automated solution that may be of use to you.
This will not allow you to recover anything automatically, but at least will let you know “how much you lost” since your previously working backup, so you can fix it manually in a new working project.
This approach requires that you have both:
- You current project
.scrivfolder (the one that you cannot open with Scrivener). Copy this whole folder to a working place in order not to risk your original copy. Rename this copy toproject_copy.scriv. - A working backup. You mentioned that you have a 2 weeks old (or so) backup. If your backup is zipped, please unzip it. Copy this unzipped folder to your working place and rename it
project_backup.scriv.
We’re now going to compare the inner structure of your project files with a utility called WinMerge, which you can download and install for free. Open it and select the 2 working folders you created previously:
AFAIK, Scrivener is unlikely to change the UUID of the inner folders (those long numbers that name the folders where the actual data is). Probably it will create new UUIDs when you create new documents. This means that the actual files (content.rtf) will show the actual changes.
Either way, with WinMerge both modified and new documents will be visible to you side by side, on a screen like this one:
As mentioned, files named .rtf are the most important ones.
If you double click on a file that has changed (red one in the picture), you will get something like this:
Here you can see that some content on the file in the right is missing from the file in the left. Reading raw RTF is not easy at first, but at least most text is easily distinguishable.
I know this is not a great solution, but it helped me reconcile my two versions with some significant work, but feeling sure that I did not lose anything I wanted to keep.
I really hope this can be of help to you. Best of luck!
1 Like
There are lots of valid reasons why a user might want to have multiple documents in a project with the same name. Among the most obvious, it’s quite common to keep multiple versions of a book in a single project. There are also many reasons to not name an item in the Binder at all.
In any case, you are suggesting a major change to the project format in order to protect against an issue that is extremely rare and can be avoided entirely by having a reliable backup strategy.
Incidentally, an alternative that I don’t think anyone has suggested is to open a support ticket, here:
and allow us to examine the project directly. With a bit of digging, we might be able to determine why the project is refusing to open, which would be a first step to recovering it more or less intact.
4 Likes
Thank you very much!
Yes, absolutely, that’s the way I will do it, many thanks.
How did you get the new / changed text and files (and folders?) to the new working project? And only the rtfs or other files or content of other files as well?
And a further problem here is not to transfer the issue. Guess, I have to close and start the backup all the time after transferring a bit to see if it still works.
Well, then he could use multiple folders (very common in Win). Or Scrivener simply would add an incrementing number to the file name internally.
Then Scrivener could do it automatically and / or add an incrementing number to the file name internally or such.
Ah, sorry, I cannot remember / I would not say to have done that. I do not have any idea of coding / program development.
Does not appear to be that rare in this forum, when I looked for information about that, I thought. Yes, of course, so better leave the issue / bug for the user, just some “rare” unusable projects / lots of work. Yes, sounds like a quite efficient approach for Scrivener, quite easy to handle, that’s how software development must be.
I absolutely would not think so. Obviously with “reliable backup strategy” you don’t mean the one of Scrivener, as it appears its “reliable backup strategy” did not work, didn’t it? But yes, a totally “reliable backup strategy” for Scrivener would be good in any case, as losing entire projects with Scrivener, because of an issue / bug in Scrivener, obviously is much more risky than with other programs, respectively does not occur with other programs at all, that’s a quite good recommendation of course.
Well, well, you could have done it all the time.
And give you all of my data, text with that project? I would think, this is a great idea, but this might not be one of the best ideas I have ever heard. Maybe exactly these kind of ideas lead to that kind of bugs, to such an unreliable program.
Above all, there is another major problem (for me): this issue, of course, obviously can occur again and again in every project. And maybe no back up (having the issue, too) might help then.
If I only had the back up (with the issue) done with a sync program (and no working backup done by Scrivener), the project simply would be lost completely. Respectively, a manually done (better a try to do) “reconstruction” (that would be more or less similar to the original, I guess much more less) would take months or much longer. More than 3000 rtfs (without the other files to recover) to get together, even 100 rtfs (by far not possible, I guess) per day about 30 full time days.
I can’t even imagine what kind of hidden talent it takes to pull off such a massively shitty and ridiculous failure as Scrivener. I’d really like to know what the people who programmed this shitty piece of shit look like. Of course, that will never be more than a wish. Just some thoughts.
But be that as it may, in any case, I very much appreciate your support and ideas. Thank you very much!
That’s a very good point to keep in mind, and hard to nail without knowing the root cause of the problem. Other users have pointed out that a 4GB project should not be an issue for Scrivener, but I would take that with a grain of salt. It may well depend on how your project is structured. For instance, if your project contains a lot of images or a large number of documents, scrivenings mode may have trouble handling it well.
I once tried to import 74K documents no larger than 256 bytes each, and Scrivener was not able to handle it.
I’d suggest you to start by creating a new working project copied from the backup project and remove everything but your manuscript. If your manuscript has inline images, convert them to file links instead. This should make your project significantly lighter.
Folders are not relevant. Just rtf files (content.rtf and notes.rtf, if you also have notes). I had to transfer the data manually.
I opened the file with Word and copied and pasted what I needed. Right click on the file you want, select Open left/Open right according to your needs and click on “With Registered Application” (in my case that is set up to be Word).
You don’t need to close Scrivener to do a backup. Check this option on your settings, and every time you type Ctrl-S a new backup will be made.
I wish you the best on your road ahead!
3 Likes
The most logical solution I’d use if Scrivener cannot access my work of the past 2 weeks would be to:
- Access the project’s scriv folder, using File Explorer.
- Next, click into the Files folder.
- Next, click into the Data folder.
- Then sort all the UUID folders according to Date Modified. It’s not turned on by default but can be easily added to the displayed info through a right click on the list names.
- Your intention should be to sort having the latest UUID folder on top for ease of use–who knows if it’s ascending or descending order—there are only 3 options anyway.
- When done, click into the respective UUID folders and access your work in the contents.rtf files.
- That’s pretty easy, hardly a train smash, or search nightmare.
5 Likes
Yes, I meant: have to close and start the backup all the time. I had to open each new backup to check whether or not the bug is transferred.
Many thanks. And many thanks for your great help.
That can obviously be done only with the original project, because the backups Scrivener did have the dates / times the backups were made.
OK, everything done so far, thank you very much!