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.
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. )
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.
[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.
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?
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?
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.
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).”
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.
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.
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.