In the last few days, when I do either an RTF or doc.x back up, I get the message (see attached screenshot) ‘Could not find this item’ about two or three files from the same directory/folder.
.ZIP back ups seem to be OK. They are processed and can be transferred without any error messages coming up, but I have not tried restoring from a .ZIP back up.
I do not understand why this is occurring, as the files are still in the project (but obviously some part of Scrivener is still being told that it is in its original location, not the one to which I must have subsequently moved it).
No, back ups are not always .ZIP files. [See the ‘Back Up As Zip File’ tick-box in File - Back Up - Back Up To].
What I meant was that, in addition to backing up as .ZIP files, I export to RTF or doc.x formats, so that they function as back ups for me. [See File - Export - Files, and choose a format it in ‘Export text files as’ and choose a format]
Someone on the scrivener reddit noticed in the screenshot that I posted that part of the pathname has ‘Part1.’ - i.e., with a full-stop/period at the end of that line - and theorized that might be part of the problem.
I had copied that file pathname from somewhere else, and when I look at it in the Binder (where I pasted part of the filename I had copied) or in the Outliner, the full-stop is not visible.
I am aware of most of the rules of naming files, folders and so on, and would never put a full-stop/period at the end of any file name.
When I went to ‘rename’ the folder, I found an extra space there (which might have been my fault), so I back spaced to get rid of that space.
I will try exporting again (to RTF and doc.x) to see if I still get the error ‘Could not find this item’.
If that does not work, how in Windows can I get into the pathname shown in my screenshot to edit it (if that is at all possible)?
Is it safe to monkey with that?
If not, is there a way of making a copy of the project, changing the pathname, so that I can then make RTF and doc.x exports to check whether it is working?
That full stop at the end of “(Part 1)” appears to be just a punctuation mark used by Windows to end the first sentence of the error message and not part of the file name. Besides, you can have multiple periods in a file name; Windows uses the last one to determine the file’s extension:
That is definitely true. Still, I wouldn’t be shocked to find (and am pretty sure in the past I’ve found) an application, even a native Windows one, and perhaps especially a not-quite-native one, mishandling a file name that contains multiple periods, or a path the includes a folder with a dotted extension, which though perfectly legal is also not very routine. Perhaps even more likely if the path or filename will be part of a link.
