Savedata
Un emplacement de sauvegarde monté devient un /savedata0 inscriptible. Le titre utilise l'API de fichiers ordinaire, et le lancement suivant retrouve les mêmes fichiers sous le code produit que le titre publie.
Notes du dépôt jusqu’au 10 octobre 2026
Où vit une sauvegarde
L'installation du jeu est en lecture seule, peut se trouver sur un support amovible, et est remplacée en bloc lorsqu'elle est mise à jour. Une sauvegarde doit survivre aux trois. PS5PCEM stocke les emplacements dans savedata/<titleId>/<slot>/ sous le répertoire de l'émulateur, indexés par le code produit que le titre rapporte. Deux dumps du même jeu partagent les sauvegardes. Deux jeux différents ne les partagent pas.
Le nom d'emplacement vient de l'invité et est assaini avant de devenir un répertoire. Les séparateurs, le deux-points du lecteur et les liens de répertoire parent deviennent des traits de soulignement. Retirer ces caractères laisserait deux noms différents s'écraser sur un seul répertoire. Un nom qui ne peut pas du tout être un répertoire se replie sur un nom fixe, parce que perdre la sauvegarde est pire que de la placer à un endroit prévisible.
Montage et vérifications d'existence
Un montage résout l'emplacement et fait pointer /savedata0 dessus. Créer un emplacement manquant n'a lieu que lorsque le titre en a demandé un. Une sonde pour une sauvegarde que le titre n'a jamais écrite obtient un résultat d'absence, ce que le titre attend. Tout ce qui est livré avec le titre reste en lecture seule. Le montage de sauvegarde est l'endroit inscriptible.
L'existence est répondue à partir du chemin de métadonnées, pas en ouvrant le fichier. Un montage qui ne réussissait qu'au moment de l'ouverture faisait échouer chaque vérification d'existence, et Jets 'n' Guns 2 réécrivait son profil à chaque lancement à cause de cela. Le listage des emplacements qu'un titre a écrits est répondu lui aussi. Le montage indique aussi s'il a ouvert une sauvegarde existante ou s'il en a créé une nouvelle. L'API de sauvegarde en forme de blocs utilise un blob distinct par titre sous sce_sdmemory, chargé lorsque le titre le réserve et écrit lorsque le titre demande une synchronisation.
Emplacements incomplets
La découverte au démarrage masque les emplacements interrompus qui ne contiennent que des métadonnées de micrologiciel ou des fichiers de préparation vides. Cat Quest III avait un emplacement de réglages reproduit ne contenant que path.txt. Le titre échouait ensuite sur un Data.dat manquant et attendait indéfiniment après son image de démarrage. La recherche saute désormais cet emplacement incomplet et continue.
Le lanceur regroupe chaque emplacement local par identifiant de titre sur la page Saves, y compris les sauvegardes écrites par une autre tuile de bibliothèque. Un build de développement sous zig-out résout le répertoire de l'émulateur vers la racine du dépôt. Un build empaqueté utilise son propre répertoire. Les démarrages en ligne de commande et par le lanceur du même paquet partagent donc une seule racine de sauvegardes.
Ce qui est en place
- Montages /savedata0 inscriptibles indexés par identifiant de titre, avec des noms d'emplacement assainis.
- Vérifications d'existence, listage des emplacements, et indication de la création éventuelle de la sauvegarde par le montage.
- Un blob sce_sdmemory par titre pour l'API de sauvegarde en forme de blocs.
- Masquage des emplacements interrompus qui ne contiennent aucune charge utile réelle de sauvegarde.
Ce qui manque encore
- Les sauvegardes sont des répertoires hôtes. La boîte de dialogue de sauvegarde de la console et la synchronisation cloud ne sont pas présentées.
- Un emplacement que le titre n'a pas demandé de créer est signalé comme absent.
- Les trophées, les activités et les autres enregistrements adossés à un compte sont en dehors de ce montage.
Mécanismes liés
Ce que ces pages décrivent