Pages: 1
Print
Author Topic: XMetaL Seems to Corrupt .XML Files  (Read 7988 times)
AndrewinKC
Member

Posts: 19


« on: March 12, 2010, 09:46:04 AM »

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!!!!


* XMetaL Error.png (10.5 KB, 483x146 - viewed 689 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: March 12, 2010, 06:14:41 PM »

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.
Logged
AndrewinKC
Member

Posts: 19


« Reply #2 on: March 15, 2010, 07:06:24 AM »

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 <copyryear> 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.
Logged
craig_83
Member

Posts: 36


« Reply #3 on: July 23, 2010, 05:33:55 AM »

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.
Logged
wongsk27
Member

Posts: 23


« Reply #4 on: September 22, 2010, 06:43:35 PM »

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
« Last Edit: September 23, 2010, 06:56:00 PM by Brian Wong » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #5 on: September 24, 2010, 01:24:40 PM »

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.
Logged
AndrewinKC
Member

Posts: 19


« Reply #6 on: September 24, 2010, 01:26:55 PM »

Not running Cirtix at my location.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #7 on: September 24, 2010, 02:48:11 PM »

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...
« Last Edit: September 24, 2010, 02:55:13 PM by Derek Read » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #8 on: September 24, 2010, 06:31:00 PM »

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: support@xmetal.com) 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.
Logged
AndrewinKC
Member

Posts: 19


« Reply #9 on: September 27, 2010, 05:39:45 AM »

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.
Logged
Pages: 1
Print
Jump to: