![]() If you look at the size of the CoreData folder, for example, it should be almost non-existent. My understanding of the CoreData location is that it is actually not where anything is located, but the avenue through which we go to find things. Well, I just click on the icon and the app opens it up for me, so I don't pay a lot of attention to where each of those Evernote notes are located. ![]() Henceforth, I will only be using the former, and quit tinkering in the external-edits folder, I have a suspicion that said tinkering will yield a few issues in the near future. This appears to the location of the backup /“temp/work copy,” that is a local iteration of the attachment/.doc that can be edited and does NOT sync. Users/moses/Library/Application Support/Evernote/accounts/Evernote/mosesmoses/external-edits/XXXXXXX-XXXXXX-XXXXXX Users/moses/Library/CoreData//XXXXXX-XXXXXX-XXXXX/ENNote/_records/0/4/2/0 Yes, I see this and sure this works, you are effectively here, if you are on a Mac: I click on the green icon instead of the attachment and everything works out fine.” You wrote: “When I use HoudahSpot, I usually see the attachment (it has some kind of code as a name) and then the note that contains it (the green icon). If someone edits the temp/work copy, it may only edit the temp/work copy on the hard drive & not the copy in the EN database. However, the work/temporary copy may not be deleted. When you save the file, EN pushes that copy back into the Evernote. In the Windows desktop, when you open the attachment from within the Evernote, EN opens a temporary/work copy. If you drop a file into an Evernote & you want Evernote to contain the most updated version, you need to open the attachment from within Evernote. I'm PC, but it sounds like the two desktop version work similarly in this regard. doc to the Enote -relied on Default Folder to record the containing folder (XXXXXXX-XXXXXXXX-XXXXXX.backup) location in the Evernote structure and thus making the Finder path easily retrieve-able, … going forward only open. My current solution: create a new Enote, attach edited. I could not use your suggestion -although I like the rationale. I am now also worried that I may have documents in the E folder structure that are not indexed and curated by Evernote, … if you know of any method to check this let me know. There is no Enote associated with the edited attachment. does not take any role in save location but it does appear that by editing an attachment independent of the associated Evernote note (Enote) and saving, saves to another location in the E folder structure. Thanks for the guidance, I have previously followed your guidance to others on this site and thank you. Both are findable with HoundahSpot only the unedited version is findable with Evernote.Īny insights on accessing the Evernote file structure and where I may be messing with it, please let me know. The unedited version is in another containing folder. The edited version is in a containing folder with a suffix. The unedited version of this document exists in Evernote. My thinking here being that this was a process that was the same as opening the document via Evernote, editing it and saving it. I like HoundahSpot, and use it to search globally as a gradually transition, e.g., Word docs to Evernote.) (I regularly use Houndah spot to search Evernotes locally but I now suspect this routine maybe causing issues. It is likely that I did this: I used HoundahSpot to locate the document (an older version - see below), opened it via HoudahSpot, edited and then saved it. ![]() I am trying to figure out how this situation came about. The document of interest (.doc) is in that last folder. Users/moses/Library/Application Support/Evernote/accounts/Evernote/mosesmoses/external-edits/ I have a file/document/.doc in local Evernote storage on a Mac that is not accessible via Evernote, I use HoundahSpot to find it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |