# Project search returning matches in documents not present in my project **URL:** \ **Category:** Scrivener\ **Tags:** support, searching\ **Created:** [January 12, 2024, 1:54am UTC](https://forum.literatureandlatte.com/t/project-search-returning-matches-in-documents-not-present-in-my-project/138668 "2024-01-12T01:54:49Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![AmberV](https://forum.literatureandlatte.com/user_avatar/forum.literatureandlatte.com/amberv/32/13021_2.png) [@AmberV](https://forum.literatureandlatte.com/u/AmberV)\ **Post date:** [January 13, 2024, 4:18pm UTC](https://forum.literatureandlatte.com/t/project-search-returning-matches-in-documents-not-present-in-my-project/138668/5 "2024-01-13T16:18:39Z")
> [@Randall\_Lee\_Reetz](#): > > …So when Scrivener imports from an external file, it leaves the original file intact in the trash folder (and sets its "Include In Compile setting to true. Also, Scrivener does this each time you attempt an Import and Split of an external text file. None of that is true, so I would say there is some other cause. What happens when you import: 1. The original file is read from the disk and passed through a conversion library from its original text format into Scrivener’s internal file format. Which library is used depends on the file format. There is a Java-based converter for ODT, but if you don’t have Java installed it will fallback to the system converter. For DOCX it uses a bespoke converter. For and RTFD the system libraries are used, as well as plain-text formats. 2. This is then further processed using bespoke code to convert various features that might not be supported directly by the system (embedded images, styles, footnotes, etc.). 3. Now that the content is prepared the software integrates it with the data model in one of two ways: 4. Internally this also involves creating .rtf files on the disk, saved into matching subfolders based on their data model and internal IDs. 5. The original content data is flushed from RAM, save for whatever is loaded into the editor. Again it has no useful purpose in the project and wouldn’t be placed anywhere. So that is why you see everything included in compile, not because it is changing anything, but because that is the core default for _all_ new items, whether they are imported or created within the software. It doesn’t matter where you create them, because this setting operates at a level beneath the Draft folder. You can drag things in and out of the draft without losing that setting, or even trash them, which is crucial because that setting is more important than where the item currently is. This is what allows people to swap books in and out of the Draft folder without losing their important inclusion settings. This is what allows people to compile material from outside of the Draft, which isn’t common, but can be achieved by compiling search results or collections. Therefore the presence of these items in the Trash must be because they were trashed at some point. Perhaps it was long ago, it doesn’t really matter too much. You have, I think from other threads, figured out how to exclude trashed items from your search results, so that resolves the main confusion that started this thread. We do have that on by default, because a common desire for searching is to locate missing things, and accidentally trashed data is a not uncommon place for things to go missing. I just wanted to point out that some other activity caused them to be in the Trash folder, so you don’t think you have to periodically clean them out when importing. There are no automated processes in Scrivener that would trash items without you doing so yourself. That folder is 100% user controlled. --- _[View the full topic](https://forum.literatureandlatte.com/t/project-search-returning-matches-in-documents-not-present-in-my-project/138668)._