Почему XmlSerializer сериализует объект в файл, содержащий нули вместо XML?

1

У меня странный случай - у нескольких клиентов бывает, что файл конфигурации, сохраненный во время выполнения с использованием XmlSerializer, сохраняется как последовательность нулей (байты со значением 0). Длина файла - это ожидаемый размер файла для данного XML-вывода (около 350 байт).

Это код, используемый для сериализации файла:

XmlSerializer s = new XmlSerializer(this.GetType());
using (StreamWriter sw = new StreamWriter(File.Create(path), Encoding.Default))
{
    s.Serialize(sw, this, new XmlSerializerNamespaces());
}

Модель файла конфигурации проста - класс с автоматическими свойствами типа string, bool, DateTime и одним свойством типа перечисления.

  • Я уверен, что File.Create с последующим сбоем не вызывает этого - если я делаю File.Create в существующем файле, он просто устанавливает его длину равным нулю.
  • Я попробовал добавить throw new Exception() s.Serialize call throw new Exception() перед s.Serialize call - также не файл виновника обрезается до нулевой длины

Что может заставить XmlSerializer выводить нули вместо реального XML?

  • 0
    Нет исключений при сериализации?
  • 0
    К сожалению, у меня нет доступа к журналам, когда это произошло, поэтому я не знаю, было ли исключение. У меня есть только доступ к файлу конфигурации, который все нули и, очевидно, не может быть десериализован.
Показать ещё 1 комментарий
Теги:
xmlserializer

2 ответа

0
Лучший ответ

Я нашел аналогичный вопрос с идеальным ответом, соответствующим моим симптомам:

От Малькольма:

Мы столкнулись с этой проблемой несколько раз в $ WORK, причем симптом был пустым файлом нужного размера, но заполненным нулевыми байтами.

Решение, которое мы нашли, это установить значение WriteThrough в FileStream:

using (Stream file = new FileStream(settingTemp, FileMode.Create,
                                   FileAccess.Write, FileShare.None,
                                   0x1000, FileOptions.WriteThrough))
{
   using (StreamWriter sw = new StreamWriter(file))
   {
      ...
   }
}

Оригинальный ответ на qaru.site/questions/1424796/...

  • 0
    Может ли это быть связано с тем, что возникает некоторая ошибка диска, и диск не может записать содержимое из кэша на диск? Неисправный диск, сбой, ssd без защиты от потери питания и т. Д. WriteThrough заставит записывающее устройство записывать данные прямо на диск и не использовать кэш дисков для производительности.
  • 0
    если это решает проблему, то, скорее всего, система теряет питание без надлежащего выключения, а кэш-память диска не очищалась. Я думаю, что @Ferdy прав.
0

Просто; это не должно. То, что вы описали, является нетипичным. Вы можете попытаться более подробно узнать об этом файле:

using (var file = File.Create(path))
using (StreamWriter sw = new StreamWriter(file, Encoding.Default))
{
    s.Serialize(sw, this, new XmlSerializerNamespaces());
}

Однако я бы ожидал, что ваш существующий код будет работать. Есть ли полностью воспроизводимый пример, демонстрирующий генерирование всего нуля?

Несвязанный, но Encoding.Default практически никогда не является правильным выбором. Не используйте это. UTF-8, вероятно, является вашим лучшим дефолтом.

Я бы посмотрел на такие вещи, как антивирус, неисправный контроллер диска и т.д.

  • 0
    Спасибо за ваш ответ. Добавление использования вокруг FileStream ничего не изменит, так как StreamWriter.Dispose вызывает Close в базовом потоке. У меня нет воспроизводимого примера, и у меня нет доказательств того, что XmlSerializer создает содержимое файла. Это происходит случайным образом и только на нескольких клиентских компьютерах в разных местах. Как вы сказали - это может быть что-то внешнее, например антивирус. Я хотел подтвердить, есть ли какой-либо путь к коду в XmlSerializer, который бы это произвел. Я постараюсь воспроизвести с разными кодировками.
  • 0
    @ Отметьте, что кодирование является отдельным, но важным - оно не вызовет проблемы с нулем, но может повредить вам по причинам чисто кодирования.
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню