Langage C#
  1. Langage C#
  3. Les fichiers enregistrés ne contiennent parfois que des caractères NUL
Intereting Posts
comment lire un fichier pdf avec des espaces vides (tel quel) ligne par ligne dans c # .net en utilisant iTextsharp Comment utiliser OAuth pour se connecter à l’API Etrade? La requête HTTP était interdite avec le schéma d’authentification client ‘Anonymous’. Le serveur distant a renvoyé une erreur: (403) interdit Comment se connecter à Windows Phone 7 à partir d’une application 64 bits Appeler explicitement le constructeur statique Comment appeler correctement les méthodes P / Invoke dans une bibliothèque de classes? Comment convertir 3 octets en un nombre de 24 bits en C #? microphone de capture c # Comment gérer découverte et composition comme deux préoccupations distinctes? Enregistrement / Capture en cours de lecture audio PreviewKeyDown pour l’application Windows Store ListBox Quel est le bon moyen de générer un thread pour les entrées / sorties de firebase database dans le service Web asmx? MVVM: connexion ViewModel et Business Logic Windows Phone 8: Comment animer la navigation d’une page? Création d’une Inputbox en C # à l’aide de formulaires

Les fichiers enregistrés ne contiennent parfois que des caractères NUL

Nous avons un problème dans notre application Windows 8.1 (WinRT) qui parfois notre fichier enregistré est corrompu. Les fichiers ont une taille de fichier correcte, mais le fichier ne contient que des caractères NUL. Le fichier doit contenir un object sérialisé au format XML.

Pour tenter de trouver le problème sans écraser le fichier, procédez comme suit:

  1. Sérialiser l’object actuel dans un fichier temporaire.
  2. Vérifier le contenu du fichier temporaire
  3. Copier le fichier actuel (vers .timestamp.xml.bak)
  4. Déplacer / remplacer le fichier temporaire dans le fichier actuel

La plupart du temps, tout fonctionne bien, mais parfois le fichier .timestamp.xml.bak et le fichier de contenu sont corrompus. En outre, le fichier journal est également corrompu (également uniquement les caractères NUL). Le fichier entier est composé de caractères NUL. Quand je regarde le chemin des fichiers-bak et du fichier principal, je constate que la taille du fichier principal est augmentée. Cela devrait être correct car un nouvel élément XML est ajouté. Mais il ne contient pas XML.

Je ne sais pas comment et pourquoi cela se produit. Cela se produit dans environ 5% des fichiers qui doivent être édités et chaque fichier corrompu survient après 5 à 20 tentatives d’enregistrement. Cela se produit également sur plusieurs tablettes.

Voici un extrait du code qui crée les fichiers corrompus: 

StorageFile file = await lDataFld.CreateFileAsync(filename + ".tmp", CreationCollisionOption.OpenIfExists); StorageFile oldFile = await dataFld.GetFileAsync(filename + ".xml"); if (oldFile != null) { await oldFile.CopyAsync(dataFld, ssortingng.Format("{0}.{1}.xml.bak", filename, DateTime.Now.ToSsortingng("yyyyMMddHHmmssfffffff")), NameCollisionOption.ReplaceExisting); } await file.MoveAndReplaceAsync(await dataFld.GetFileAsync(filename + ".xml")); Logger.Log(ssortingng.Format("Saved {0}.", filename));

Quelqu’un peut-il me dire comment nous nous retrouvons avec des fichiers contenant uniquement des caractères NUL et comment / pourquoi cela se produit? Et encore mieux comment cela peut être corrigé.

Un petit ajout: nous ne pouvons reproduire ce problème d’aucune façon, cela se produit uniquement dans notre environnement de production.

Les seules raisons pour lesquelles je peux penser que cela peut produire ce résultat sont:

  • Le système d’exploitation tombe en panne (BSOD) au milieu d’une écriture de fichier
  • L’application se termine au milieu d’une écriture de fichier

Je suppose que c’est la deuxième raison.

Compte tenu de cela et du fait que vous dites que c’est une application Windows runtime et que je suppose que l’application n’est pas arrêtée manuellement, je suppose que cela a à voir avec le cycle de vie de Windows Runtime . Étant donné que l’application UWP peut être “suspendue” lorsqu’elle passe en arrière-plan, elle peut être terminée par le système d’exploitation à tout moment en mode “suspendu” (très similaire aux systèmes d’exploitation mobiles comme sur Android ou IOS).

Donc, étant donné cela, je suppose que votre application commence les opérations asynchrones avant d’être suspendue, puis suspendue / terminée avant la fin de l’écriture de votre fichier.

La solution consiste à bien marquer votre application en indiquant qu’elle effectue un travail “en arrière-plan” lors de l’écriture de votre fichier afin que le système d’exploitation ne vous suspende pas lors de l’écriture de votre fichier. Pratiquement tous les systèmes d’exploitation mobiles disposent de ce type de fonctionnalité pour vous permettre de “surpasser” un peu afin de vous assurer que vous pouvez effectuer votre travail avant que votre application ne soit suspendue / arrêtée. Pour les applications UWP, consultez les tâches en arrière-plan ou examinez la manière de gérer la suspension / le report d’application d’une application .