Support says there is no way to salvage my backup

According to support, they cannot make my esi file accessible to another device. Bummer.

"Since you are able to save the esi.Backup file on an external SD card, it is not actually possible to run the backup file to a different device. That is the reason why you’re getting an error that the file belongs to another device, the files save in your SD card are the files from the device that is capable of reading the same file system."

I suggest anyone who makes important notes not only back up (for possible recovery on the same device) but also email yourself a PDF copy of your important journal notes.

"capable of reading the same file system" -- almost sounds like another EE could read them. But then, the PE should be able to, and that's what you tried, right?

I am so sorry this happened to you. Thank you for using your woes to help the rest of us. Very good suggestion about using email to backup important notes.

Are you going to try getting your EE fixed?

I would think any device that can read the esi file should be able to use it, but, who am I to think. And no, I am certain the cost of repair will not be worth it.

can you try openning this esi file somehow? Perhaps is a compressed file? Maybe you can just extract the journal files.

Have you tried to rename the .esi file with a .zip extension ?
(make a copy first...)

This trick works for journal and calendar files. library backup files shoiuld be good candidates for being zipped...

Two things. First, have you tried copying your SD card to a mini SD card and seeing if you can read it in your PE? To do things like that I use a USB multi card reader.

I have just copied the SD card from my EE to a micro SD them put said micro into an adapter and put it in the EE which reads it without problems - OK not quite your situation but it does prove the copy procedure works,

Second, and I must admit I have a curiosity factor in this, if you have definitely decided NOT to have your EE repaired is there any chance you might do an 'iFixit' type breakdown? I want to see what is inside and am loath to open my working one just in case, in fact if I was in the US I would make an offer on broken machine just to be able to take it apart.

You might also find the iFixit opening of the iPad2 interesting http://www.ifixit.com/Teardown/iPad-...eardown/5071/1 if only for showing how the cables are connected.

I'm pretty sure the reason for this device incompatibility is that enTourage used the device's unique serial number to encrypt the backup file, allowing only the same device to decrypt and therefore restore the backup file.

Lets take a moment of silence. An old friend has past. Sorry for your lost Cheyennedonna. Sounds like that Eee transformer is in your future.

Originally Posted by maspears

Lets take a moment of silence. An old friend has past. Sorry for your lost Cheyennedonna. Sounds like that Eee transformer is in your future.

Better get on the waiting list now--it's sold out everywhere.

Hmm, the .esi file itself is no problem - as Qwill already suggested, it is really just a .zip of your library files. If you take your copy to the PC and rename it to "xxxx.zip", you can easily access all your files again.
This way you can at least easily regain your pdfs, pictures, books etc. You can even get to your journals etc. and using the EdgeSync tool you can at least read them on your PC. However, as of yet, I am not able to get esi files back into the edge - the point is not so much that the mac address would be encoded in the file, but that entourage registers all library entries in a database which I haven't quite "hacked" yet. Why the guys from Entourage should not be able to port esis between different edges, though? Beats me!

This is terrible news! So sorry.

It's true that the .esi file is just a zip, and it's true that the PDFs and EPUBs are all there. However, the meta data, like the db's and annotation files, may still be somehow encrypted using the original device's ID, or the issue may be the Adobe registration for the original device will not be valid on the new device (since each device registers uniquely with Adobe).

They're the ones that created the backup/restore system for the Library, so it was in their control to enable/disable restores to other devices. I'm sure they must have had a good reason, either security or Adobe.

I did a backup of the library on my edge, copied the .esi file to another computer (a vm of opensuse running on XP so I can see the file in both places.)
Linux identified the.esi file as a zip file, so I copied it to another file ending in the .zip extension and then Windows identified it as a zip, file too.

The usual tools on Windows and linux read the zip file fine, there's no password, or apparent encryption in the file .zip file itself.
The .esi/.zip contains two backed-up, absolute paths, /fridge and /sdcard.

Here's a list of all the directories containing one or more files in the .esi/zip:
/fridge/.edge/.esi-data/.databases/
/fridge/.edge/.esi-data/.edb/
/fridge/.edge/.esi-system/
/fridge/.edge/.esi-system/.fontconfig/
/sdcard/.edge/.esi-content/
/sdcard/.edge/.esi-content/.esa/

I can't say what prevents the files from being read on another edge if the files are unpacked in their appropriate places.

Using Windows and Linux to navigate to the location of a commercial book I bought, Adobe Reader in both cases reports, "This document requires (DRM) features supported by Adobe Digital Editions... ... blah blah". So, Acroread reads the file and recognizes the DRM. I'd figure the file should be readable on another system with the proper user/password from original purchase.

Journal files are named jrnl_*.esj in /sdcard/.edge/.esi-content directory. Linux says they are just .gzip compressed. The variable part of the filename appears to be a hash value or date/time expressed as a hex string. Using gzip to uncompress a file shows me plain text:

<?xml version="1.0" standalone="no"?>
<xournal version="0.4.2.1">
<title>ESI journal v1.0</title>
<author>Kenneth Jennings</author>
<page width="396.00" height="540.00" tabname="">
<background type="solid" color="white" style="lined" />
<layer>
<stroke tool="pen" color="black" width="1.41">
79.68 12.00 80.16 10.56 81.60 9.60 83.04 9.12 84.48 9.60 84.48 11.04 84.48 12.48 84.00 13.92 83.52 15.84 82.56 17.76 82.08 19.20 80.64 20.16 79.68 18.72 81.12 17.28 82.56 16.80 84.00 17.28 85.44 18.24 85.92 19.68 
</stroke>
blah blah blah...etc

So, journal files are apparently not encrypted/specific to the edge that created them.

I took a compressed journal file renamed it (jrnl_test.esj) , uncompressed it (to jrnl_test2.esj) , and moved the two files back to the edge in my generic Documents directory on the sdcard.
The Storage browser shows the uncompressed and compressed copies both as journal files.
It would not open either file directly, instead prompting to add them to the Library first.
After adding both files to the library, and going to the Library view in the Storage file browser I located them in the Journals section.
The Library/Journal app opens both files just fine.

So, to salvage a journal file
1) uncompressing the journals isn't necessary.
2) Rename the files to something meaningful. They only have to end in .esj


So, as far as I can see, most of the stuff in the backup file should be salvageable. Purchased books will have DRM applied, so you'll need the appropriate pin/user/password that Adobe expects to open the book on another device.

PDF files with annotation would be harder. There's the pdf file, then there's the annotation file, and a database that relates the two. Making that work together would require duplicating what the Library does to relate them in the database.

It looks like the annotations themselves are stored in the .esa directory under the library's .esi-content directory and named: *.esa and they contents are also compressed journal files.

The database files related to documents are also apparently not encrypted:

Sifting through the backup, here's a journal and a related database file:

lxtest:/media/vbox/edge_backup # find . -print | grep 4c8e313d
./fridge/.edge/.esi-data/.edb/jrnl_4c8e313d.edb
./sdcard/.edge/.esi-content/jrnl_4c8e313d.esj

linux tells me the file is a recognized database:

lxtest:/media/vbox/edge_backup # file ./fridge/.edge/.esi-data/.edb/jrnl_4c8e313d.edb
./fridge/.edge/.esi-data/.edb/jrnl_4c8e313d.edb: SQLite 3.x database

sqllite has no complaints about the content, either:

lxtest:/media/vbox/edge_backup # sqlite3 ./fridge/.edge/.esi-data/.edb/jrnl_4c8e313d.edb
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /media/vbox/edge_backup/./fridge/.edge/.esi-data/.edb/jrnl
sqlite> .tables
bookSections
sqlite> select * from bookSections ;
1|jrnl_4c8e313d||0|jrnl_4c8e313d|0|1
sqlite>