I was working on a novel in Scrivener 3 on Mac when the two attached error messages came up one after another. I’ve no idea what they mean or why appeared but I may have hit a few keys together that caused it. The thing is that I use Dropbox only for storing Scrivener backups (both zipped and unzipped files and the long number looks like it belongs to Scrivener having looked at the contents of a file. But where the two files exist in Dropbox I have no idea, if they actually do. I keep clicking on Cancel but it does no good and rebooting didn’t remove the problem. Can anyone help, please?
The “long numbers” are Universally Unique Identifiers (https://en.wikipedia.org/wiki/Universally_unique_identifier) which are used by computer systems to keep track of items instead of using names, which might be duplicated.
The message you are getting is from Dropbox, not Scrivener. It is telling you that you are intending to move a file from somewhere in your Dropbox folder into another folder that is outside your Dropbox folder – apparently into a Scrivener project that is NOT in your Dropbox folder.
I’m guessing, but it may be that you have (perhaps unintentionally) tried to move some files from a Scrivener project that is stored in Dropbox into a Scrivener project that is stored elsewhere. However, notes.rtf might be from somewhere else, and I’m not familiar enough with Scriv project structure to know if the other file is from inside a project or not.
If I were you, I would allow the move to take place, then restore from a Time Machine or other backup.
This is a case that demonstrates that Dropbox ought not to be the only backup strategy. Time Machine or other backups are really essential for safety.
Thanks for your reply. I decided to go ahead and allow it. That seemed to be the only way to remove the error messages. Dropbox is just a copy of a backup section for Scrivener projects. But that backup section is also backed up to Time Machine, iDrive and to external bootable copies on Carbon Copy Cloner. I have not made any adjustments yet, though I may replace the files from CCC to the backup folder. My main concern is my present project, a novel I’m trying to finish. It doesn’t appear to have been affected but since I’ve been working on it continually I don’t want to go back to an earlier version. But I can save it elsewhere and restore the rest of the backup file and hence Dropbox from CCC as I suggested.
If you’re creating “automatic” backups that are not .zip compressed, the message may be due to the removal of the oldest backup copy.
By default, Scrivener numbers its backups (instead of using dates in the backup names), and depending on your settings, will replace the oldest backup once you reach the limit set in your Scrivener preferences (by default, 5). It’s possible that between that oldest backup and your newest backup, you just deleted a document’s notes.
Dropbox recently modified it’s behavior to warn of deletions ( don’t recall it doing this before a couple of months ago), but I think it has always treated the replacement of a folder (which is all that a project really is) and its contents as an update to the parts that are different from the old copy. If my hypothesis is correct, that’s why I think replacing an old, not-zip-compressed project didn’t result in one of those messages for every document, synopsis, and document note in the project, as Scrivener (effectively) deleted the old backup and then replaced it with a similar, but not identical copy of the current work in progress.
Thanks for your reply. I’m not sure what you’re saying applies. My automatic backups are set to zip files. I recently changed from saving 25 backups to 10 because I didn’t think I needed the higher number. Whether that has anything to do with the error messages I don’t know. But hopefully, it won’t happen again. I’ve just copied my back-up folder as saved in Carbon Copy Cloner a few days ago over my current back-up folder and that has synced with Dropbox so everything should be right now.
Mike,
This has nothing to do with your error messages, really just me butting in, but…:
-
Sounds like you’re keeping both your zipped backups and your project files on DropBox. There have been cases where DropBox accounts or folders have been inadvertently deleted, with the result that the folks impacted basically lost everything. Best practice is to not keep zipped backups and live projects on the same cloud service.
-
You mentioned you’ve recently cut the number of zipped backups from 25 to 10. The easiest way to restore a damaged or corrupted Scrivener project is via Scrivener’s zipped backups. What typically happens with a corrupted project scenario is the person opens and closes the project many times, trying to ascertain what is wrong, before they finally realize the project is borked and they need to restore from a zipped backup. But at that point they’ve opened and closed the project so many times, they’ve exceeded their “# of backups to keep” setting and Scrivener has deleted all of the good backups taken prior to the corruption event. Best practice is to keep as many zipped backups as you can.
But it sounds like you’re backing up your system from many different directions, so please ignore the above advice if you feel you’re sufficiently covered. 
Best,
Jim
Thanks, Jim.
Drat! It’s happened again and for no apparent reason. Though this time it stopped after I clicked on Cancel seven or eight times. It seems to happen when I’m working in Composition mode. That’s the only pattern I can see. Time I contacted Dropbox I think.
If you have got an alert giving a UUID it ought to be fairly easy to find which folder the file is being moved to. You can show the package contents, then sort the folders in list view according to their filename to make a visual search easier. When you have found the right folder, you can look at the content rtf file to find out where the folder is in the binder hierarchy. It might just give you an idea of what is happening.
OK – I’ve just done a search on my HD using Commander One Pro, looking for files with dat.nosync in their name. There are loads of them (170 on my machine) in the Library folder. They are hidden files because of the stop being the first character in the name, hence you can’t find them by normal means. The majority of these files are inside the Application Support folder, but some are inside Preferences, Synced Preferences, or Caches. So I’m wondering if somehow you may have copied something from inside the Library folder which has taken a hidden file with it, and Dropbox is alerting you when attempts are made (in the background) to move it.
Thanks for your replies. I’m somewhat baffled. I did a search for dat.nosync files in Dropbox and in my backup file that is synced to Dropbox. I found one in each case, the same file I think which is as it should be. I don’t want to start fiddling around in deeper stuff so I cleared out Dropbox and resynced my backup file to it hoping that has sorted it. If not then I may have to resort to what you’re suggesting. I’m trying to finish a novel for a competition deadline that’s coming up so don’t want to get sidetracked.
Okay, I decided to find the offending file as you suggest and it is obviously alien to Scrivener. None of the other numbered/lettered folders contains such a file. The dat file is identical in size to the notes.rtf file also mentioned in an error message and also contained in the folder where it is at home, judging from the other folders.
I opened the DAT file in BBEdit and got the following which contains the text in the rtf file: Monday afternoon/evening.
{\rtf1\ansi\ansicpg1252\cocoartf1504\cocoasubrtf830
{\fonttbl\f0\fswiss\fcharset0 Optima-Regular;}
{\colortbl;\red255\green255\blue255;}
{*\expandedcolortbl;;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\partightenfactor0
\f0\b\fs28 \cf0 Monday afternoon/evening
\b0
}
Does any of this mean anything to anybody? Would I be right in thinking that removing the DAT file from the backup folder should sort everything out . . . however it got there in the first place. Clearly it doesn’t belong.
I don’t have much to illuminate this, I’m afraid. The part from "{\rtf1 " up to the closing curly brace is just an rtf file. It seems to have had the text “Monday afternoon/evening” in it, and nothing else – which might help you identify where it came from. I note that it was in the Optima-Regular font, which I think used to be the default Scrivener font, and I don’t know of another program that normally uses it. In any case, I would think that with the backups you have, you could probably safely delete both files and proceed from there. If there is trouble, restore from backup and think again.
Thanks for your reply. I decided to delete the dat.nosync file from my backup folder (and from Dropbox too) since it didn’t belong and left the rft file since it did and everything seems to be working now. I haven’t seen the error messages for a while. The text involved was fairly minor, Just a side note, so I doubt it messed anything major up. But I’m puzzled how it started in the first place.
I would hazard a guess that this is a case of corruption caused by incomplete synchronisation. I’ve known cases where Dropbox shows all the right icons (suggesting it has completed a sync), but it is actually still working. Flipping the lid shut on a laptop too soon or doing something similar can mess things up. And moving files is very quick, but it is not instantaneous. Sometimes we are too quick for our devices.
Good point! Thanks.
It’s happened again but in a different scene. And it always seems to start while I’m working in compose mode. So frustrating!!! I rarely turn my computer off so I don’t think it can be anything to do with incomplete syncing.
Ah … well that is the opposite of my normal practice. I may be old-fashioned, but I am a firm believer in closing down all programs that are not being used and shutting down the computer when not in use. I just like to make sure I have cleared out the memory, severed all connections with the outside world, and am starting with a blank slate for every session. Unix experts will probably say that this is completely unnecessary, but it has become my habit.
Don’t know what to suggest except perhaps “fumigating” the project by creating a new, blank project on your hard drive, and dragging your work bit by bit into that from the present project. In the past, I have split a project into several smaller projects just for the sake of greater focus and ease of working. A faff, I know, but constant irritations and stoppages are no help to good writing.
I don’t have the time to be doing that right now. A deadline is looming. What I may do is a clean install of Sierra once the deadline has passed. I can’t recall when that last happened so it’s long overdue.
Mike, sorry if this has been suggested already , but why don’t you just move your live project files out of Dropbox for the time being ? My impression was you aren’t using it to sync multiple devices, so really no need to keep the project on DB.