You’d think after working with this product since V3.2, I’d know this stuff…
I thought the id file was required:
When the user logs into Notes.
When the user unlocks an id after hitting F5
Following a timed user logout
Yep, no ID, can’t log into Notes.
Nope… I locked my workstation, moved the id file out to my Windows desktop, and signed back in noooo problem.???
Nope… Same as #2
How can I unlock my id if my id is missing? Why did Notes let me re-enter my password and let me back in?
I’ve followed and read many of the Redbooks/White papers on ids and these mostly talk about how the id works with the passwords and encryption and… but nothing about use sequences.
Well, a memory cache of the ID file would explain 2 & 3. That would be the file itself, in all its encrypted glory, since successfully decrypting the file is the only “password check” that Notes has. I’d wait for a definitive answer from Dave Kern, though.
You got it right, Stan – the encrypted ID file is read into memory to avoid excess disk I/O, and when the password information used to decrypt the ID is cleared through F5 or timeout, Notes loses the ability to decrypt that in-memoy cache until the password is re-entered.
Has this caching always been there, or was it introduced sometime after Notes 4? I seem to remember, that setting the ID file to read only would give permanent errors back then, but I could be very wrong here.
I’d have to check the code to see when this changed. Originally, as you mentioned, the ID file I/O was designed to minimize use of memory, so individual pieces of the ID file were read into memory as they were needed. Also, tickets were stored in the ID file, so the ID file was written to disk reasonably frequently.
Over time, when holding the entire ID file in memory was no longer an issue, we shifted to reading the entire ID file into memory once, then performing the piece-wise “reads” and decrypts out of the in-memory copy. Additionally, the tickets were moved from the ID file into a separate file, which greatly reduced the frequency of ID file writes.
Technically, we still don’t support ID files on read-only media or shared media, including network file shares, but AFAIK running in that configuration will no longer result in corruption of the ID file.
I’ve been running Notes via network share since, well a long time (10 years maybe?) in both 4.6 and 6.5 and we’ve never seen an id file corruption. About the only issue we run into is when the user is on a wireless leg of the network - slow response times can result in some interesting problems - user looses connection to the server, etc. Other than that, storing the id (and names.nsf and bookmark and desktop6) doesn’t seem to be an issue.
Interesting information - thanks for the reply!
Doug
Technically, we still don’t support ID files on read-only media or shared media, including network file shares, but AFAIK running in that configuration will no longer result in corruption of the ID file.
