Official response on the Evernote Purgatory directory

[GreyGray 15]

On the Macintosh, Evernote creates a directory called "purgatory" that on my machine, is loaded with hundreds of folders that look like the same random UID named folders of the real data. Only these appear to be deleted items.  

 

1) Can these files safely be deleted?

2) What are all possible storage locations for purgatory on the Macintosh?

3) Should they be getting auto cleaned up or not?

4) Why the disparity in size compared to my data, it is much larger, as is the case for most?  Perhaps we are all testing a lot and deleting a lot?

 

With answers to these questions I will be able to make a small app that cleans this purgatory directory of it's stagnant files on schedule.

[Metrodon 2,188]

This is a user forum, you may get lucky and get a staff response to this but your best bet would be to open a support ticket.

 

My guess would be that they will tell you that messing with app data is completely at your own risk and wouldn't be supported.

[JMichaelTX 4,118]

@GreyGray:

 

If you do a Google on "Evernote Purgatory folder" you might get some insight.

[GrumpyMonkey 4,320]

On the Macintosh, Evernote creates a directory called "purgatory" that on my machine, is loaded with hundreds of folders that look like the same random UID named folders of the real data. Only these appear to be deleted items.  

 

1) Can these files safely be deleted?

2) What are all possible storage locations for purgatory on the Macintosh?

3) Should they be getting auto cleaned up or not?

4) Why the disparity in size compared to my data, it is much larger, as is the case for most?  Perhaps we are all testing a lot and deleting a lot?

 

With answers to these questions I will be able to make a small app that cleans this purgatory directory of it's stagnant files on schedule.

 

Hi. I don't know if you will get an official answer, but this is a location that has caused consternation in the past (at least, for me). See this thread I made about it a couple of years ago -- I think that is when purgatory started appearing.

https://discussion.evernote.com/topic/40736-evernote-purgatory-and-type-ahead-index-on-the-mac/

 

1. It seems OK, though it won't speed up your account or anything.

https://discussion.evernote.com/topic/40736-evernote-purgatory-and-type-ahead-index-on-the-mac/?p=220158

 

2. Don't know.

 

3. Don't know.

 

4. Dont' know. The Mac version of Evernote has had ballooning database issues in the past. I imagine that the more text you have, the larger your "extra" space will get, because it has to index everything.

[GreyGray 15]

 

On the Macintosh, Evernote creates a directory called "purgatory" that on my machine, is loaded with hundreds of folders that look like the same random UID named folders of the real data. Only these appear to be deleted items.  

 

1) Can these files safely be deleted?

2) What are all possible storage locations for purgatory on the Macintosh?

3) Should they be getting auto cleaned up or not?

4) Why the disparity in size compared to my data, it is much larger, as is the case for most?  Perhaps we are all testing a lot and deleting a lot?

 

With answers to these questions I will be able to make a small app that cleans this purgatory directory of it's stagnant files on schedule.

 

Hi. I don't know if you will get an official answer, but this is a location that has caused consternation in the past (at least, for me). See this thread I made about it a couple of years ago -- I think that is when purgatory started appearing.

https://discussion.evernote.com/topic/40736-evernote-purgatory-and-type-ahead-index-on-the-mac/

 

1. It seems OK, though it won't speed up your account or anything.

https://discussion.evernote.com/topic/40736-evernote-purgatory-and-type-ahead-index-on-the-mac/?p=220158

 

2. Don't know.

 

3. Don't know.

 

4. Dont' know. The Mac version of Evernote has had ballooning database issues in the past. I imagine that the more text you have, the larger your "extra" space will get, because it has to index everything.

 

 

I read your thread which I found googling around for purgatory.  I am like you, in that mine just blows up in size.  They appear to be items I deleted from EN, and I have in fat nuked all the files in that location to no I'll effect, it has been a month, so I assume it is ok, but I would like an official response on what it is, not if it is ok for me to delete, unless they want to also part with that information.  But just telling me what it is for, what is supposedly in it, etc., that is enough for me to go ahead and release a EverNote cleaner script that will fix that among other things.

 

I think you had issues with performance.  As far as I can tell, from search indexes to the actual data, most of EN, aside from images and other "binary" type objects, end up in an sqlite database.  This is the same database Apple's OS X uses for all it's internal workings.  Spotlight, etc, all that stuff is backed inside sqlite.  I have read that sqlite, which is a very simple, yet amazingly powerful and super fast local database, can do 10 million rows in the database in sub second queries. That it can do that with many hundreds of thousands of simultaneous connections to it.  

 

In our case, we only have one connection to the database, maybe two if we are syncing or working and the remote EN servers put something in EN, that will be backed by sqlite.  As a rough estimate, EN uses more than one record per note in it's database. Lets say it uses 5.  Lets say you have a ton of notes, maybe even a million, that means 5 million entries in sqlite.  It should be able to do that without breaking a sweat.  

 

The problem is, when you have a database, it is in many way like a file system, and they all behave different.  In this case, I believe deletions in sqlite are not truly removed, and you have to run a command called vacuum to regain the space.  There could be index's that need tuning, or worse columns that have no indexes on them at all, making search very very slow.  I have not had time to open up all the EN databases and look at them.  The ones I have opened, hmm, they are set up in an interesting way.  It is certainly hard to tell what they are up to with the strange naming conventions that are used.  It looks like even the database has been created in a way to try to obfuscate certain areas so anyone looking at it will have a hard time tracing where things are coming and going to and from.

 

The good news is, we can add indexes, vacuum, and do all sqlite database management to the databases ourselves, wrap it up in a "Tune EN" script, and have it do it's thing.  It is just a matter of time before I will have a chance to look at it deeper.  I also want a few releases to come out so I can compare the databases and make sure they don't change the db structure too often.  That would break the TuneUp script.  Ideally, EN incorporates the functionality of the script in EN if we see performance gains.