Newest update 6.3.3.3502 Changes DIR for dB wihout option to defer

[RgaDawg 35]

And why on god's green frickin earth did we need to automatically change the DIR being used for the database and files with the newest update to v 6.3.3.3502. I get it there is a message that says you can change it again in options, but attempting to do this creates a file being locked in Windows. I'm pretty sure that everything re-synced with the server, and my notes seem to have the same count after I changed the data DIR back to my desired location. But, if ain't broke, don't fix it ..

Bad, bad, bad .. Next time don't do it automatically. ASK! Some of us actually use a different DIR for the data

I've never had to re-sync the entire database since I've been using EN, I've always felt very secure about the syncing, used on 2 computers and 1 android. My specific DIRs are set to backup from those locations.

Come on guys, gals, think it through the next time.

Signed, a very long time subscriber to EN whom has never needed any support nor complained about anything, even the recent price changes.

[jefito 5,589]

23 minutes ago, RgaDawg said:

 

And why on god's green frickin earth did we need to automatically change the DIR being used for the database and files with the newest update to v 6.3.3.3502.

 

The basic reason for moving it is described here: https://discussion.evernote.com/topic/98127-new-for-evernote-622-beta-release/?do=findComment&comment=421373. Essentially, their original location *was* broken; they've made the default be the correct location. There's further discussion in the ensuing beta release topics, as this feature hit more beta users, including from Evernote staffers.

I've successfully moved my database to a new location (SSD) without difficulty; not sure why you had a problem. I did take the precaution of backing up my entire existing database folder before I changed from the default location. I didn't need to sync my whole note database down, fortunately.

[RgaDawg 35]

Thanks Jefito. Mostly a rant. This didn't happen on my laptop until the 6.3.3.3502 update, and it didn't happen at all on my desktop. It just caught me off guard. I've always completely trusted EN with much data I use across devices and it didn't settle with me very well.  If I had caught the Notice mentioned in the post for v 6.2.2.xxxx, then I would have certainly provided some feedback, but I don't usually consume my time reading all the blogs and notices from software I use. I just trust it to work without breaking anything.

From a developer point of view, if the original location was broken, then it would have been a pretty easy task to check if a custom DIR was being used or the "broken" one. Then leave things alone if the former rather than the latter. As mentioned in my original post ASK. there could have easily been an option in the dialogue to keep current DIR or allow EN to change it.

The automatic swap from my custom DIR to <Evernote Path> of course went very quickly, but when I reset back to my Custom DIR from > options, then the entire dB downloaded again from server (which is likely the best way to insure the dB is intact). I did have everything backed up quite well, but it would be impossible to do any kind of cross reference to determine if everything is intact. Now, I simply have to trust that all the resetting and re-syncing was exact.

I'm pretty sure that happened since the data sync is on server.

[RgaDawg 35]

I'm guessing the assurance I seek that everything is intact is that the application itself syncs with a server copy, and all devices sync with that copy as well. So, since my laptop downloaded the entire dB, then that should be the correct action for EN to take.

[RgaDawg 35]

Newest update 6.3.3.3502 Changes DIR for dB without option to defer has created serious problems ..

As an afterthought, just to feel comfortable that the laptop upgrade well, I decided to do a binary compare, and was quite disturbed that even before a binary compare, both file sizes differed by 342 MB

It doesn't look like the upgrade on the laptop went well when EN on that pc updated to 6.3.3.3502. The size between the desktop and laptop dB *.exb has a difference of 342 MB. The *.exb on my desktop (which left everything in my custom DIR when upgrading to the v6.3.3.3502) shows a [username]*.exb of 587 MB, the laptop (which automatically changed the DIR when going to the 6.3.3.3502, which I then went through > options > DIR location to change back) shows the [username]*.exb to be 245 MB. There are also various other DIR's that are missing or the wrong size between the two machines.

I have shut down EN on my laptop until this is resolved and when I once again trust that EN has all my data intact. I seriously do not want anything from the Laptop to sync to the Desktop (or server) at this point until I am sure it won't create further problems. I would take EN on my Android offline as well, but the message EN says is that all Cache and offline files will be deleted. Kinda a scary message.

I will open a support ticket at this time. I just wanted to follow up on this discussion so that anyone with a similar problem might see that some serious problems could happen with that automatic swap of directories on the Update.

There goes another 3 hours of my time ... Also as referenced in the response to my original post, it was stated that the situation referred to beta users. I never subscribe to beta releases, and I assumed the 6.3.3.3502 was safe

[RgaDawg 35]

On 10/1/2016 at 10:41 PM, jefito said:

The basic reason for moving it is described here: https://discussion.evernote.com/topic/98127-new-for-evernote-622-beta-release/?do=findComment&comment=421373. Essentially, their original location *was* broken; they've made the default be the correct location. There's further discussion in the ensuing beta release topics, as this feature hit more beta users, including from Evernote staffers.

I've successfully moved my database to a new location (SSD) without difficulty; not sure why you had a problem. I did take the precaution of backing up my entire existing database folder before I changed from the default location. I didn't need to sync my whole note database down, fortunately.

Newest update 6.3.3.3502 Changes DIR for dB without option to defer has created serious problems ..

As an afterthought, just to feel comfortable that the laptop upgrade well, I decided to do a binary compare, and was quite disturbed that even before a binary compare, both file sizes differed by 342 MB

It doesn't look like the upgrade on the laptop went well when EN on that pc updated to 6.3.3.3502. The size between the desktop and laptop dB *.exb has a difference of 342 MB. The *.exb on my desktop (which left everything in my custom DIR when upgrading to the v6.3.3.3502) shows a [username]*.exb of 587 MB, the laptop (which automatically changed the DIR when going to the 6.3.3.3502, which I then went through > options > DIR location to change back) shows the [username]*.exb to be 245 MB. There are also various other DIR's that are missing or the wrong size between the two machines.

I have shut down EN on my laptop until this is resolved and when I once again trust that EN has all my data intact. I seriously do not want anything from the Laptop to sync to the Desktop (or server) at this point until I am sure it won't create further problems. I would take EN on my Android offline as well, but the message EN says is that all Cache and offline files will be deleted. Kinda a scary message.

I will open a support ticket at this time. I just wanted to follow up on this discussion so that anyone with a similar problem might see that some serious problems could happen with that automatic swap of directories on the Update.

There goes another 3 hours of my time ... Also as referenced in the response to my original post, it was stated that the situation referred to beta users. I never subscribe to beta releases, and I assumed the 6.3.3.3502 was safe

[jefito 5,589]

2 hours ago, RgaDawg said:

As an afterthought, just to feel comfortable that the laptop upgrade well, I decided to do a binary compare, and was quite disturbed that even before a binary compare, both file sizes differed by 342 MB

Binary compare on .exb files is not particularly meaningful. Evernote's .exb file is a SQlite database, SQlite implements certain conventions about modifications to the database for performance sake. For example, deletions may not make the physical size of a database file any smaller; that space is just marked as deleted and it may be therefore be reusable later on. See, e.g., http://stackoverflow.com/questions/2143800/change-sqlite-file-size-after-delete-from-table/2143808#2143808, http://stackoverflow.com/questions/35787220/sqlite-file-size-not-decreasing-after-deleting-some-rows-from-database-in-ios, etc.

2 hours ago, RgaDawg said:

I would take EN on my Android offline as well, but the message EN says is that all Cache and offline files will be deleted. Kinda a scary message.

This is normal behavior for Evernote. Notes on mobile devices are typically cached when accessed; whole notebooks are not downloaded except in the case of offline notebooks. So long as you've synced any changes up to the Evernote servers, logging out of Evernote (and losing cached notes and notebooks) should be safe. See e.g. https://discussion.evernote.com/topic/67486-request-ability-to-switch-accounts-with-android-phone/

 

[RgaDawg 35]

17 minutes ago, jefito said:

Binary compare on .exb files is not particularly meaningful. Evernote's .exb file is a SQlite database, SQlite implements certain conventions about modifications to the database for performance sake. For example, deletions may not make the physical size of a database file any smaller; that space is just marked as deleted and it may be therefore be reusable later on. See, e.g., http://stackoverflow.com/questions/2143800/change-sqlite-file-size-after-delete-from-table/2143808#2143808, http://stackoverflow.com/questions/35787220/sqlite-file-size-not-decreasing-after-deleting-some-rows-from-database-in-ios, etc.

 

This is useful. I am working with support ticket now. They are very helpful.

I did have an after thought that the Desktop dB was not optimized and when the Laptop downloaded the dB it was optimized.
Other dB's work the same as SQLlie when deletions, etc occur. unless a compact or optimization is specifically run, the file size is larger than the optimized version

I have rebuilt the Laptop dB, and I suppose support will want me to just go ahead and rebuild the Desktop, which will optimize the dB. I guess I am just a little uncomfortable and don't want to lose data.

I did do a size comparison between backups of both pcs (exports) of *.MHT, *.ENEX, even *.HTML and they seem to be correct.

I am going to just rebuild the dB on the Desktop. I just wanted to feel more comfortable about that.

- Thanks for your responses

[jefito 5,589]

8 minutes ago, RgaDawg said:

This is useful. I am working with support ticket now. They are very helpful.

That's great to hear. Hopefully this all works out well for you, despite the time you've put into it. The export backup file size comparison was a nice idea.