Scrivener 3.0.1.0 (1274647) 64-bit, Windows 10 Home
I use Scrivener for managing my projects, but another program for actually writing. Since editing files directly in the .scriv project folder is a very bad idea, I make extensive use of External Folder Sync in order to dump the contents of my Drafts folder elsewhere and then sync it back in when I’m done. However, i noticed that if I delete a folder/file while rearranging things and then delete it from trash before syncing, the sync just brings it back.
Settings I’ve applied, if needed:
Sync the draft of the contents folder
Prefix file names with numbers
Take snapshots of affected documents
Check external project on folder open/close
Format for external Draft files: RTF
However, here’s something I noticed. Steps to replicate:
In drafts, create two folders, foo and bar.
Sync with external folder.
Send both folders to trash.
Delete ‘foo’ permanently.
Sync again. Notice that ‘foo’ now gets synced back in.
Delete ‘bar’ permanently.
Sync again. Bar doesn’t get synced back in.
This didn’t occurred on 1.9 and I don’t know if the Mac version does the same thing so I’m unsure if this is intended change or not.
Using the same settings for Sync, I was able to confirm the behavior your describe with the foo and bar folders.
I’m finding that when items are moved from the draft folder to the trash, and then the external folder is synced, the corresponding items in the external folder structure are (as expected) moved from draft to trash. But if the trash folder is emptied in Scrivener, items in the external folder remain behind, but they are not brought back into S when it is resynced.
After syncing my main project just now, there are 4 items in the trash, but the external trash folder has 14 items.
After emptying the trash in S and then resyncing, the external trash still has 14 items, but the S trash remains empty.
Not sure how trash syncing is supposed to work, but it doesn’t seem as though the external sync folders, even just the trash folder, should be able to remain out of sync after being synced.
I have to agree with you regarding “Why won’t this stuff just DIE?”, but this is how it’s always worked on Mac. grumbles The problem is that the Trash (in Scrivener) folder is not synced as such. Rather, the Trashed Files external folder gets a copy of anything that is either deleted from Scrivener or deleted externally to Scrivener. So I’ve had to empty the external Trashed Files folder manually for… more years than I care to think about. And the Scrivener Trash too, of course.
I believe this is as designed, so if you’d like it changed you’ll likely need to post to Wish List. The designer, KB, is super paranoid about deleting files, and declined a related request of mine (automatic trash emptying) several years ago. I doubt this request will go far but it can’t hurt to ask… much.
I suspect the issue here is that if you sync after deleting a file from the trash, there’s nothing saying “this file was deleted.” So the sync sees a file in the external file that doesn’t exist in the project and adds it again. Somehow syncing while it’s in trash and then deleting it does mark it as deleted though.
Encountering this behavior again. It’s not easy to figure out what is happening and under what condition. But having the the Sync function return to the binder documents that have been deleted is not a desirable behavior.
One thing I’ve noticed (or think I’ve noticed) is that the files that Scrivener places in the Sync folder’s “Trashed Files” subfolder are not only getting undeleted and returned to the binder after running sync, but that a new copy of each of these files is created when it gets deleted again from the binder. So the Trashed Files folder ends up with files named like this.
2 a document [1] 1.rtf
2 a document [1].rtf
9 doc name 1 [8] 1.rtf
9 doc name 1 [8].rtf
After a series of tests where I alternately deleted files and then ran sync, always using the same 4 files which would get returned to the binder post-sync, the Trashed Files folder had 32 files in it.
It’s not clear why the sync “Trashed Files” folder wouldn’t be treated the same as “Drafts” and “Notes” are, and simply be a mirror of the binder. As it happens, it appears that docs from Trashed Files are being reentered into binder, while previously deleted copies of those docs also accumulate in “Trashed.”
Emptying the binder trash, and also emptying the sync Trashed Files folder, BEFORE running sync, would seem to prevent this.
Documents that have been sent to the trash can end up being “silently” returned to the binder without notice or any obvious indication just by running sync.
I won’t pretend to know what specific condition causes it.
What I know is that I’ve been working in a project that I’ve now discovered has hundreds of unwanted duplicate documents in the binder, in some cases 3 or 4 dupes of the same doc, each identically named except for the appended binder position number they get via the sync process.
I understand the paranoia about deletions and the various protections and confirmations built into Scrivener. But when a document has been sent to the trash, it should stay in the trash under all circumstances, and the sync process should be able to deal with trashed items without reinstating them into the active working mix of “live” documents. Offhand, I’d be fine if Sync ignored trash altogether, neither syncing it out to disk nor syncing it back in to the binder; whatever purpose syncing the trash folder might serve in principle, it is clearly not working reliably and safely; better to “trash” the sync-trash function altogether if it can’t be fixed.
Routine “deletion paranoia” is nothing compared to the paranoia involved in cleaning up this mess, for which project backups are of little use, as they too contain a rolling assortment of reinstated trashed documents, some of which have been inadvertently worked on as though they were the originals.
Note to self and all:
I will now wait to be told that somehow this is because of how Qt works, and how Windows just can’t do this or that, and the subtle hints that if I was serious I’d be using a real operating system.
I prefer the nuclear option: I very seldom empty the trash folder, and when I do, I clear out/empty the external sync folder prior to syncing again. Obviously it would be better if Scrivener didn’t force us to resort to these measures, but this way seems fairly foolproof to me.
I apologise for my cavalier post earlier. I’ve now tried this on Mac. This appears to be a Windows bug! On Mac, nothing that was permanently deleted in Scrivener ever gets synced back in. Yes, copies accumulate in the “trashed files” sync folder, but to get something that was permanently deleted into my Scrivener project, I have to deliberately import it from the Trashed Files. Repeat, this appears to be a Windows bug.
I have no way of testing the assertion:
Since the Powers That Are have ignored this thread so far, I suggest that a concerned Windows user (@Mad_Girl_Disease ? @ownedbycats ?) report the issue formally via Bug Reporting. I would, but since I have no Windows machine to test workarounds/fixes, the report would go nowhere fast…
Just in case someone benefits from this, I used to have syncing problems. Now I DO NOT SYNC normally. But, when I need to, I mark the documents for that sync and make and sync a new collection. Then sync only the new collection. No trash, nothing that isn’t the new collection. Then I edit and sync back. Then no more syncing until I need to edit again. All my problems were resolved.
This might not work for you, but it saved me a lot of frustration when someone here recommended this procedure.
Well, I can confirm it’s still a problem, as I’m dealing with it right now. I delete the file from Trash, delete the folder “Trashed Items” from the sync, it seems gone, and then I open Scrivener up again and it’s back somehow.
but it can’t hurt to ask… much.