#How to turn on autosave in pages code#
Maybe there is a bug in the code compacting the package built at first.Īs I already explained, iWork builds a package then, And most often these corrupted documents are flatfiles. The number of corrupted files received exploded after the introduction of iWork '09. I guess that because sometimes I was said that the document was killed after the addition (or the removal) of a single character. I would not be surprised if it is linked to the most common oddity: an instruction which doesn't manipulate correctly a carry when the treated data cross a page boundary. My guess is that there is a bug pushing the code to write a wrong instruction. When the Index.xml file is available, I may decipher it and rebuild the entire document but Pages is unable to do the same, simply because, somewhere among the thousands of instructions, there is one which it is unable to decipher. The corrupted files, at least those which I received, are always readable with standard tools, at least with Hexadecimal editors. The operating system is fooled by the wrong descriptor available in its HD's table of contents. Most often, a document corrupted by a power shortage is not readable with current tools like TextEdit or TextWrangler. Every time the response is: no, it was on a single user system. But when I receive such ones, I always ask the owner if the doc was stored on a server where it may be used by several machines. I know a way to get documents without Index.xml file. In my own use I never got a corrupted document but, contrarily to what you often wrote, when I receive a corrupted file, I don't state: the user made something wrong. I receive in my mailbox documents sent by users asking me to try to recover the embedded content.
0 kommentar(er)
