General XMetaL Discussion

XMetaL Community Forum General XMetaL Discussion XMetaL Seems to Corrupt .XML Files

  • AndrewinKC

    XMetaL Seems to Corrupt .XML Files

    Participants 8
    Replies 9
    Last Activity 12 years, 6 months ago

    I am authoring topics in XMetaL 5.5 and encountering issues when saving my XML topics. The end result is that I end up with zero-byte XML file for my topic. The pattern seems to be…

    I create a new DITA topic (doesn't matter if it is concept, task, or reference). The topic initially saves as a 1KB or 2KB .XML file. If I edit the prolog information in the tag view (especially the copyryear tag) and then save the file, I get an error saying the file cannot be saved. If I look at the folder in which the file is saved, it is now a 0 byte file. Sometimes doing a Save As with a different filename works, sometimes it doesn't.

    Has anyone else encountered this issue?

    Help!!!!

    Reply

    Derek Read

    Reply to: XMetaL Seems to Corrupt .XML Files

    I can't reproduce this yet, but if your “I” drive is a special mapped drive I would not be reproducing your setup in my tests.

    Is it possible that this drive has problems? If so, saving files to it from any other application might fail approximately at the same rate. Perhaps the “I” drive is mapped to some network share, or a removable drive, or something else that might be temporarily disconnected?

    It may also be worth checking the integrity of this drive using an application like Windows scandisk or similar tool.

    If this is an ongoing issue you may wish to start saving your files to your local machine's C drive (or another physically connected drive) to check that it doesn't happen when saving there. If it doesn't occur this way then that puts more suspicion on the “I” drive itself being part of the issue.

    Reply

    AndrewinKC

    Reply to: XMetaL Seems to Corrupt .XML Files

    I did a bit more testing over the weekend and was able to narrow the issue down to a specific sequence. What is unusual about this is that XMetaL did not behave this way until last week. Been running it for about three weeks now.

    I create a new topic and then save the topic with no changes. The result is a 1KB .XML file. I then go to edit the tag (in tag view) and save the file, the file that was 1KB before is now a 0KB file and cannot be saved or renamed. The only option is to delete and start over.

    My I: drive is a mapped network drive that I use to save files from every application I use throughout the day. No recent problems with the network drive. I tried this on my desktop with no issues.

    Reply

    craig_83

    Reply to: XMetaL Seems to Corrupt .XML Files

    I had a similar issue.

    The xml file was also on a network drive. The user saved the document, that triggered the XMAX save method.

    The resulting xml file was a 0 byte file.

    The user reported they got a validation error, which was a custom message we built for if the xml file for if it becomes invalid, working off the XMAX document valid property.

    We are using XMAX 5.5.

    Reply

    wongsk27

    Reply to: XMetaL Seems to Corrupt .XML Files

    Dear Sir/Madam,

            I  have the same problem with XMetaL 5.5 Essential as well but my document in save on a normally drive. After XMetaL crash, my XMLdocument become 0 bytes. I have done a couple of tests, trying to understanding what is going on. What I discovered is that when XMetaL save a XML document, XMetaL first creating a temp file like “sqtmp01..”, afterward the file size of the file I save become 0 byte, then a few secs later, the temp file will be removed by XMetaL and the file I saved will be returned with the correct file size. I suspect something happening to XMetaL during the process of transfering data from temp file to the target file and causes XMetaL crash, then make my xml file remains 0 bytes.

    -Brian

    Reply

    Derek Read

    Reply to: XMetaL Seems to Corrupt .XML Files

    We have a developer looking into this.

    Can you confirm that you are running XMetaL Author Essential in a Citrix environment? We have some code specific to Citrix that writes out a zero byte file in order to test that the location being saved to is writable before writing out the actual file. It could be that something is occurring here to cause that code to fail triggering the code that actually writes out the file to also fail.

    I don't believe this should occur unless you have installed the product on Citrix, but if you could confirm that it will be useful.

    Reply

    AndrewinKC

    Reply to: XMetaL Seems to Corrupt .XML Files

    Not running Cirtix at my location.

    Reply

    Derek Read

    Reply to: XMetaL Seems to Corrupt .XML Files

    Thanks. I've passed this info on to the dev team.

    How often is this occurring for you?

    It would seem that there are currently only three clients seeing this issue, you and the other two on this thread. No reports have come in through support yet so hopefully there is something unique to your setup that might help us track this down.

    If others on this thread can guess anything that might be unique to their setups as well please pass those along here. I'm guessing things that might interfere with the file system would be most likely, perhaps some security software, encryption, virus scanning, that type of thing. If you can detail your OS version (XP SP3 for example) that might also help. If this only occurs for large documents, the customization you are using runs a lot of script just before or after saving, if a CMS connector is involved, etc…

    Reply

    Derek Read

    Reply to: XMetaL Seems to Corrupt .XML Files

    We've tracked down the code responsible for writing out the zero byte file. My last suspicion was correct to some degree. We are actually (by design) writing out a zero byte file as a test to see if the location being written to is writable. This code runs regardless of OS (not just a Citrix thing). Then once the zero byte file has been created successfully additional code is expecting to be able to overwrite it with the document that is in memory (ie: do the actual save). It is this second part that is failing.

    AndrewinKC:
    As you're the only person working with DITA on this thread it will be easiest to get a sample from you. A DITA topic should not require any additional configuration files in order to reproduce the issue you are seeing — and we're hoping to get a sample that will trigger the issue here. (for the other people we would likely need their DTDs and the rest of their customizations as they are working with XMAX and XMetaL Author Essential)

    The next time you notice this happen can you switch to Plain Text view, copy the entire document to the clipboard (Ctrl+A then Ctrl+C), then paste it into Notepad, save it, and forward the file to XMetaL Support (email: [email protected]) referencing this thread. Hopefully having a copy of the file will allow us to trigger the exception that is occurring during the save operation so we can try to reproduce the problem exactly and address it.

    Reply

    AndrewinKC

    Reply to: XMetaL Seems to Corrupt .XML Files

    Thanks for the follow up. I was experiencing this issue when running XMetaL 5.5. I have since upgraded to 6.0 and no longer encountering this issue.

    I am still having an issue with a conflict between XMetaL and McAfee though.

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support