有时保存的文件仅包含NUL个字符 [英] Saved files sometime only contains NUL-characters

查看:234
本文介绍了有时保存的文件仅包含NUL个字符的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的Windows 8.1应用程序(WinRT)中存在问题,有时我们保存的文件被损坏.这些文件具有正确的文件大小,但是该文件仅包含NUL字符.该文件应包含序列化的XML对象.

We have a problem in our Windows 8.1 application (WinRT) that sometimes our saved file gets corrupt. The files have a correct file size, but the file only contains NUL-characters. The file should contain a serialized object as XML.

为了发现问题,我们不覆盖文件,我们执行以下操作:

In an attempt to find the issue we do not overwrite the file, we do the following:

  1. 将当前对象序列化为临时文件.
  2. 检查临时文件的内容
  3. 将当前文件复制到.timestamp.xml.bak
  4. 将临时文件移动/替换为当前文件

大多数情况下,它们都可以正常工作,但有时.timestamp.xml.bak文件和内容文件会损坏.除此之外,日志文件也会损坏(也只有NUL个字符).整个文件包含NUL个字符.当我查看bak文件和主文件的轨迹时,我发现主文件的大小增加了.这应该是正确的,因为添加了新的XML元素.但是它不包含XML.

Most of the time this all works fine, but sometimes the .timestamp.xml.bak-file and the content file get corrupt. Besides that, also the log file gets corrupt (also only NUL-characters). The whole file consists of NUL-characters. When I look at the trail of bak-files and the main file, I see that the main file is increased in size. That should be correct because a new XML-element is added. But it doesn’t contain XML.

我不知道发生这种情况的方式和原因.它发生在大约5%的应编辑文件中,并且每个损坏的文件都会在5-20次保存尝试后发生.它也发生在几种平板电脑上.

I do not have a clue how and why this happens. It occurs in about 5% of files which should be edited and each corrupt file happens after 5-20 save attempts. It also happens on several tablets.

以下是创建损坏文件的代码片段:

Here is a snippet of the code which creates the corrupt files:

StorageFile file = await lDataFld.CreateFileAsync(filename + ".tmp",  CreationCollisionOption.OpenIfExists);

StorageFile oldFile = await dataFld.GetFileAsync(filename + ".xml");
if (oldFile != null)
{
await oldFile.CopyAsync(dataFld, string.Format("{0}.{1}.xml.bak", filename, DateTime.Now.ToString("yyyyMMddHHmmssfffffff")), NameCollisionOption.ReplaceExisting);
}
await file.MoveAndReplaceAsync(await dataFld.GetFileAsync(filename + ".xml"));

Logger.Log(string.Format("Saved {0}.", filename));

有人可以告诉我我们如何最终只包含NUL字符的文件以及这种情况为什么发生吗?甚至更好的解决方法.

Can someone tell me how we end up with files containing only NUL-characters and how/why this happens? And even better how it can be fixed.

一个小招数: 我们无法以任何方式重现此问题,只能在我们的生产环境中发生.

A small adition: we cannot reproduce this issue in any way, it only occurs on our production environment.

推荐答案

我能想到的可能产生此结果的唯一原因是:

The only reasons I can think of that may produce this result are:

  • 文件写入过程中操作系统严重崩溃(BSOD)
  • 该应用程序在文件写入过程中终止

我认为这是第二个原因.

I'm assuming it's the second reason.

鉴于此,而且您说这是Windows运行时应用程序,而且我猜该应用程序不是手动终止的事实,我想这与

Given this and the fact that you say it's a windows runtime application and I'm guessing the application is not being terminated manually, my guess is that it's something to do with the windows runtime lifecycle. Given that UWP application can be "suspended" when it goes to the background and then may be terminated by the OS at any point while in the "suspended" mode (very similar to mobile OSes like on Android or IOS).

因此,我的猜测是您的应用程序在挂起之前先启动异步操作,然后在完成文件写入之前被挂起/终止.

So given this, my guess is that your application starts async operations before it gets suspended, then it gets suspended / terminated before it completes your file writing.

解决方法是确保您将应用标记为在执行文件写入时正在执行后台"工作,以使操作系统不会在文件写入过程中挂起您的应用.几乎所有移动操作系统都具有这种类型的功能,可让您稍微超载"以确保您可以在挂起/终止应用程序之前完成工作.对于UWP应用,请检出后台任务,或研究如何

The fix is to make sure you mark your app saying it's doing "background" work while it's doing your file writes so that the OS will not suspend you during your file writing. Pretty much all mobile OSes have this type of feature to allow your to "overrun" just a little to make sure you can get your work done before your app is suspended / terminated. For UWP apps check out background tasks or look into how to handle app suspend / postponing app suspend.

这篇关于有时保存的文件仅包含NUL个字符的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆