I am having a hard time tracking this one down. I cannot reproduce it. I noticed the other day that for about a two weeks now (according to my dated backups) the project file I have been working on seemed awfully bloated. So I opened up the Bundle and found nearly 400 RTFs. Only around 100 of these are valid, 50-ish being represented in the Binder, and the other 50-ish being their corresponding note files.
The other 300 were documents that I had batch imported a while ago (definitely post beta 2, though, as I did not start this file until after that was released). It was just a test import to see if web sites retained their internal linking. These files had long been sent to the trash, and the trash had long been emptied, but they remained in the project bundle despite.
None of them had corresponding note files. Perhaps those are only created on demand? I backed up my project and then deleted them all. So far everything seems to be running just fine, though I am carefuly going through everything to make sure all is well. I might just make a new project file, and drag everything over from the old project’s Binder to be safe.
So, could be a freak thing. Like I said, I haven’t been able to reproduce it yet, but might as well have it on file. If anyone has excessively bloated project files for no reason – might want to take a look. If this has happened more than once, it will be easier to track down.
Strange… You are right in your assumption that notes files are only created as needed - and actually, this is true of all files, but obviously an import is slightly different as the files already exist and are being imported.
The only reason I can think of that these files would not have been deleted even though they were deleted from the binder is if Cocoa’s -removeFileAtPath:… method failed for some reason - ie. if the file physically couldn’t be removed from disk. I can’t think of a reason for this, though. Anyway, I have added some code for beta 3 that will spew an error if any of the files can’t be deleted from disk for some reason. In this circumstance, they will also be left in your binder from now on. At least that gives you some indication that something is wrong and more accurately reflects that you have some other files hanging around.
Definitely one to keep an eye out, for, though, as I cannot recreate this at all. Did you ever encounter a crash while emptying the trash? (There was a bug I have fixed for beta 3 whereby the app could hang whilst the trash was being emptied.)
P.S. I take it there is no chance that this could be something to do with your backups? For instance, I use iMSafe, which can be set to move new files to backup but not delete old files. It occurs to me that in this situation, Scrivener files could be backed up with updated binder information whilst the older files remain in the bundle in the back up. But this would only affect backed-up files…
No crashes during trash operations. Actually, I do not think I have had any crashes since B1, but I could be forgetting something. The only peculiarity that I could think of, was a few occasions when I might have worked off of my thumb drive. This shouldn’t be a problem though, since that drive is formatted with HFS+ just like everything else is. Sometimes weird things happen with USB, though. Maybe those Cocoa delete calls just didn’t work; got sent too fast for the interface or something.
The backups that I noticed this problem with are merely Scrivener projects created using “File/Backup Project To…” and then compressed with Zip. My main backup is with Retrospect, and I am not sure how it handles bundles, but either way I haven’t done any restoration from backup, so it moving deleted RTFs back in would not be the case. I do know how Retrospect handles deleted files. It marks them as not existing in the snapshot, but if you roll back to an earlier snapshot they will appear in the catalogue and can be restored. Anyway, that is all academic since I haven’t restored anything.