Bonjour,

je travail sur un pc gaming (Quixant), celui-ci est utilisé dans les jeux forain/casino car il peut être éteint en coupant directement sont alimentation. (pratique dans les boutiques car au soir power off via disjoncteur générale).

afin de faire un bootloader (mis ajour) via une clé usb, j'utilise la structure SHFILEOPSTRUCTA pour copier des fichier.

mon application se lance donc automatiquement a l'allumage du pc.
si elle detecte une clé usb (à l'allumage, power on) avec le bon dossier , elle enclenche la procédure de mis a jour:

la mise a jour contient un dossier media_new et un fichier application_new.exe qui remplaceront le fichier application.exe en cours de fonctionnement et du dossier media

1) copie du fichier application_new.exe et du dossier media_new de la clé usb sur le disque
2) renommage fichier application.exe en application_old.exe et du dossier media en media_old
3) renommage fichier application_new.exe en application.exe et du dossier media_new en media
4) suppression du fichier application_old.exe et du dossier media_old
5) exit du programme
6) power off de la machine - retirer la clé usb (sinon le boottload redémarre) et power on apres 1 minutes de pause.

LE PROBLEME: avec certaine clé usb au redémarrage power on apres un boottload, un ou plusieurs fichiers sont parfois corrompu (image .png) et plante toute l’application.

si je n'effectue pas de power on, je clique directement sur le fichier.exe apres le bootload pour relancer l'application je n'ai jamais ce problème.

je quitte pourtant le programme afin de bien libérer toute les ressources au cas ou j'en aurais oublier une mais !!!

avez vous une idée ?

un bout de code pour expliquer la copier des fichiers:

SHFILEOPSTRUCTA sh;
bool error = false;
 
//copy media
sh.hwnd = NULL;
sh.wFunc = FO_COPY;
sh.pFrom = usbKeyFolderMediaPath00;
sh.pTo = applicationFolderPath00;
sh.fFlags = NULL;
sh.fAnyOperationsAborted = false;
sh.hNameMappings = NULL;
sh.lpszProgressTitle = NULL;
 
if (SHFileOperationA(&sh) != 0) {
MessageBox(NULL, L"bootload downloading error 1", NULL, NULL);
}

Moi, je n'utiliserais pas les API "de base Win32" pour faire ce genre de manipulation mais je me pencherais vers les API spécifiques aux installateurs qui disposent de primitives tel que l'écrasement d'un fichier par un autre lors du prochain reboot (pour la gestion des fichiers de services, etc...).

SHFILEOPSTRUCTA/SHFileOperationA, ça utilise des ASCII mais MessageBox utilise l'UNICODE, une raison à se mélange un peu casse-gueule ?

Avec ce genre d'API, l'utilisation de ZeroMemory les structures, c'est généralement pas optionnel pour éviter des artefacts dedans.

Avoir la nature de la corruption, ça permettrait de faire des hypothèses raisonnables sur la ou les sources du problème, c'est des troncatures de fichiers des structures des répertoires, que dit "chkdsk" sur l'état du système de fichiers, etc...

>plusieurs fichiers sont parfois corrompu (image .png) et plante toute l’application

De nouveau l'utilisation des API d’installateurs devrait permettre d'utiliser des CRC pour vérifier la correction de ces copies.

>je quitte pourtant le programme afin de bien libérer toute les ressources

La fin d'un programme n'est pas un "moment de grâce" où tous les tampons de lecture/écriture du système de fichier vont se "flusher", juste parce qu'un descripteur de fichier est automatiquement fermé au moment de la fermeture du programme.

Si vous êtes dans un "environnement" où vous ne laissez pas faire son travail correctement à l'OS : laisser le temps à l'OS de flusher ses caches d'entrée/sortie, via un onduleur et des notifications UPS par exemple ; vous ne devez pas compter sur lui pour qu'il fasse ce type de "miracle".

Avez-vous fait en sorte que vos manipulations sur fichier ne soit pas "bufferisées" ?

Je ne suis pas sûr que le problème vienne des clés USB mais plutôt de l'état de charge des tampons d'entrée/sortie du système de fichier, donc plus au disk dur ou à son contenu (sa saturation en terme de $MFT, etc...).

Si le contexte d'utilisation de ce type d'ordinateur est de maltraiter l'OS à coup de shutdown à la bourrin, l'éditeur de ces bécanes ne fournit-il pas des solutions clé en main pour votre problématique "très" spécifique ?

Merci pour votre aide,

je débute en C++ et j'ai déjà pas mal galéré pour réaliser ce projet.

> API spécifiques aux installateurs qui disposent de primitives tel que l'écrasement d'un fichier par un autre lors du prochain reboot (pour la gestion des fichiers de services, etc...).

avez vous un lien ou je pourrais étudier la question?

> Avez-vous fait en sorte que vos manipulations sur fichier ne soit pas "bufferisées" ?

comment peut on s'en assuré ?

>Si le contexte d'utilisation de ce type d'ordinateur est de maltraiter l'OS à coup de shutdown à la bourrin, l'éditeur de ces bécanes ne fournit-il pas des solutions clé en main pour votre problématique "très" spécifique ?

je me renseigne de suite via le constructeur/distributeur mais a part après un bottload, les machines ont toujours démarré correctement.

encore merci pour votre aide et tout lien ou référence me sera extrêmement utile.

>je débute en C++ et j'ai déjà pas mal galéré pour réaliser ce projet.

Je ne pense pas que c'est le langage qui soit le plus gros challenge de ce type de projet.

Il faut une bonne connaissance du ou des systèmes d'exploitation, pas du langage.

>avez vous un lien ou je pourrais étudier la question?

C'est fonction de la plateforme/framework d'installation que vous comptez utiliser.

Quasiment tous fournissent des mécanismes d'installation transactionnels avec des CRC sur des fichiers, etc...

Sous Windows, ils se servent généralement des services offerts par Windows Installer pour faire tout ce genre de sale boulot.

A la fin, c'est des primitives comme MoveFileEx (et des flags comme MOVEFILE_DELAY_UNTIL_REBOOT) qui feront tout le boulot :

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexa

Mais le but, c'est de ne pas le faire à la main mais via des plateformes/framework d'installation qui s'occuperont de tous ces détails.

Pourquoi ne pas avoir simplement fait un MSI avec une installation "administrative" ?

>comment peut on s'en assuré ?

Bin, en caractérisant les erreurs : étendues, patterns, structure des fichiers, etc... Si vous savez comment fonctionne "vraiment" un système de fichier bufferisé, cela devrait être assez évident, voire évident à tester (avec des fichiers fait pour).

Avant de vous plonger dans la littérature, il faut que vous aillez une vue précise des défauts de copies, pas juste "ça marche pas".

(Mais pourquoi faire une installation sans installateur ???)