140     /* They are requesting information about the generic blob_id. */  in stat()
310         /* 2a) are they opening the active image? this can only happen if they  in open()
313         /* 2b) are they opening the active hash? this can only happen if they  in open()
319     /* Check that they've opened for writing - read back not currently  in open()
327     /* Because canHandleBlob is called before open, we know that if they try to  in open()
328      *  open the verifyBlobId, they're in a state where it's present.  in open()
341              * aren't open because of the fileOpen() check. They can still open  in open()
363             /* When in this state, they can only open the updateBlobId */  in open()
385     /* To support multiple firmware options, we need to make sure they're  in open()
386      * opening the one they already opened during this update sequence, or it's  in open()
387      * the first time they're opening it.  in open()
391         /* If they're not opening the hashBlobId they must be opening a firmware  in open()
403                 /* Previously, in this sequence they opened /flash/image, and  in open()
404                  * now they're opening /flash/bios without finishing out  in open()
422     /* How are they expecting to copy this data? */  in open()
432     /* We found the transport handler they requested */  in open()
447     /* Do we have a file handler for the type of file they're opening.  in open()
472         /* 2c) are they opening the /flash/hash ? (to start the process) */  in open()
653             /* They are closing a data pathway (image, tarball, hash). */  in close()
656             /* Add verify blob ID now that we can expect it, IF they also wrote  in close()
665             /* They haven't triggered, therefore closing is uninteresting.  in close()
694             /* They haven't triggered the update, therefore this is  in close()