|
|
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\fi-1800\li1800\tx1800\cf1\b\f0\fs20 From:\b0\tab Henry Lee (Exchange)\par\b Sent:\b0\tab Monday, November 08, 1999 6:00 PM\par\b To:\b0\tab Alex Armanasu (Exchange)\par\b Cc:\b0\tab Mike Hillberg (Exchange)\par\b Subject:\b0\tab Office usage of EFS\par\pard\cf0 I haven't gotten any meeting notes from anyone, so I've included my own.\par\parAttendees: Sekar Chandersekaran\par Praerit Garg\par Robert Gu\par Teresa Fung\par Mike Hillberg\par Brian Andrew\par\parProblem: When you edit an encrypted file in Office, and the parent directory is not marked as encrypted, the newly saved file will not be encrypted. This is because typically Office will do a safe-save (create temp, rename, rename, delete).\par\parThe first proposed solution involved the use of the hTemplate parameter in CreateFile, where the hTemplate refers to the original encrypted file, and CreateFile is being used to create the new version of the document. This was deemed not scalable and robust by Brian Andrew due to NTFS volume locking concerns.\par\parRobertGu is proposing a new API to move EFS metadata from one file to another. This API has not been fully designed yet, but it could take two handles or two filenames as parameters. Robert had some concerns about the parameters being handles since EFS may do a separate open on the destination.\par\parThe original plan was for StgCreateStorageEx to accept either a source handle or filename, and then pass this parameter to the new API to transfer the EFS metadata. The work to do this is trivial, probably a day or two of work to expose the new parameter can pass it down to the new API. It is possible to not change the StgCreateStorage API by first creating a zero-length file with the correct EFS metadata (note: this works in normal mode but not in simple mode). Then StgCreateDocfile can be used to fill in the contents. Phil seems to prefer this approach.\par\parThere was general agreement that the new API should not be limited to encryption. It could be expanded to transfer other types of metadata, such as ACLs, compression, etc. Note that ReplaceFile does this, but also copies the contents as well. There was also discussion of what should happen when encryption is about to be lost. Current behavior is silence. There was agreement that the "Save" operation should preserve encryption, but "Save As" is debatable.\par\parNext, the discussion broadened to include different ways of losing encryption besides saving to the file system. These include: saving to a different format with mutiple files (like HTML with thicket), saving with WebDAV, saving into an embedding, saving into an email message, saving into Platinum store.\par\parThe only action item that came out was that Mike will spec out the new API, and it will be reviewed at the next meeting. Also Mike now works for PradyM on XMF, and he's not sure that he should be owning this work.\par\parLast week, I investigated docfile bugs #422632 (red-black tree problem) and #420996 (incorrect data during low-memory when copying a 4G stream -- the out-of-memory condition is causing by memory-mapped a 2G scratch file). I've declared both as postponed, and eventually, I'll go back and investigate them further as needed.\par\parThanks,\parHenry\par\pard\fi-1800\li1800\tx1800\cf1\par}
|
