GetSaveInfo Rare Fail

General
#1

My Mac/PC app remembers the last document opened and reloads it on launch. Rarely, but on a regular basis, the app will be unable to construct a FolderItem from the GetSaveInfo causing user panic when they think their document has gone.

I get the save info via

theSaveInfo = theFolderitem.GetSaveInfo(nil, 0) theSaveInfo = EncodeBase64(theData, 0)

and store it in a preferences file. I retrieve it via

dim theFolderItem as FolderItem theFolderItem = GetFolderItem(DecodeBase64(theSaveInfo)) // theFolderItem = nil on fail

Here’s an example of a SaveInfo that won’t reconstruct (base64 encoded) APHRcwECAQAAAAFEAAAAAAFEAAIAAA1MaXR0bGUgT3JhbmdlAAAAAAAAAAAAAAAAAADNClnWSCsAAAAAAAIJZGVsbWUub3RkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT3tM7nR1Z0ZXh0T0ZUTf

(I assume there’s no way to extract the path from a SaveInfo that won’t reconstruct. )

Anyone think of anything obvious?

#2

I have been using GetSaveInfo for the first time recently and since then, I have used it a ton and have had no issues. But I’m saving mine into an SQLite database table without messing with encodings. Also I use GetRelative to open the file but I’m not sure why or how it works because I copied the code from one of the examples and never looked back.

#3

Thanks!
I tried the GetRelative instead of GetFolderItem without effect.

#4

Is it only certain folders that cause it to fail?

#5

Alas, I don’t know because I can’t read the SaveInfo. I’ll start saving the path separately for debugging.

#6

From the LR…
“NOTE: The returned string is not intended to be human-readable and any modifications may render it useless.”

#7

[quote=57628:@Roger Clary]From the LR…
“NOTE: The returned string is not intended to be human-readable and any modifications may render it useless.”[/quote]

You can, however look at the data and get some clues.

Your base64 string decodes as follows:

echo 'APHRcwECAQAAAAFEAAAAAAFEAAIAAA1MaXR0bGUgT3JhbmdlAAAAAAAAAAAAAAAAAADNClnWSCsAAAAAAAIJZGVsbWUub3RkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT3tM7nR1Z0ZXh0T0ZUTf' | base64

gives a binary string which includes some human-readable text:

җsDD
Little OrangeÕ
Y÷H+	delme.otd˜¥ŒÁGVtextOFT

Does that provide any clues? I believe this means the file creator is ‘OFT’ and the file Type is ‘text’. The file name may be “Little Orange” (or perhaps this its he volume name?) and there’s something called “delme.otd”. I wonder if “delme” stands for “Delete Me” and could possibly be a file or folder that was trashed?

#9

Or is it possible the file was simply moved by your users to some other directory and they are expecting your application to know when they move it from the original directory? But of course if you as the developer are testing this on your computer, you as the developer know when you moved it. Is this being reported only by your users or have you been able to reproduce the failure on your computers as well?

#10

The reason to use GetSaveInfo in the first place is that, in most situations, it will accurately track a file that has been moved (it does this by tracking the file’s ID on disk, rather than the file’s name and path). Of course, there are some situations where it won’t work: if the file is Deleted, or is on a Volume that is not mounted, etc.

#11

Michael, that’s good stuff to know.

#12

Is that true on Window or just OS X?

  • Karen
#13

I wonder that myself as I am confused by the reference text:

“Allows saving FolderItem references without relying on the absolute path.
The returned string indicates a relative path with is relative to the folder passed in RelativeTo. You may pass nil to indicate that you do not care for a relative resolution of the path (this is, for instance, still useful on OS X where renamed and moved files can still be found with the FolderItem.GetRelative function nonetheless).”

#14

Which platform re you seeing it fail on ?
On OS X the nay reason I can think of that it would fail is the volume the item was on is not present any longer.
Other than that the data is basically an alias - so it should find it even if its been moved.

On Windows & Linux however there’s nothing like an alias so it basically relies on an absolute path name.
if its moved or renamed then you still won’t find it.

#15

It seems to happen on both platforms. I’m going to assume user error for the moment and store the path separately for debugging purposes to see if I can get more clues. I appreciate everyone’s follow up.

#16

On rare occasions, I’ve seen a case where OS X will mis-identify a file when using this technique. I believe it only happens after something major happens (e.g. your hard drive crashes and you have to restore from a backup). You can end up with one “File ID” which points to the wrong file. Very bizarre when it happens.

To protect for this, I added some code which, after restoring a folderItem, checks to see that the .Name is the same as the we expected.

I’ve never seen this happen on Windows, just OSX.

#17

Interesting. I’ll add some sanity checking and see what happens.

#18

FYI, years later, I have discovered why storing GetSaveInfo sometimes fails.

  1. Save file to remote drive or network disk. Remember path in a FolderItem.

  2. Disconnect remote drive temporarily.

  3. Try to extra SaveInfo from FolderItem representing the remote drive. Save that to disk.

  4. Restart app with drive now connected. GetSaveInfo no longer points to a valid location.

Basically if FolderItem does not exist when you extract GetSaveInfo from it, the string won’t be valid.

#19