Le piège : le fichier est là, donc on croit que la copie est bonne — alors qu’elle est tronquée. (L’éventuel message d’erreur de scp part sur stderr (standard error) correspond à la sortie des messages d'erreur et de diagnostic. Ces messages ne sont pas toujours visibles. Il est possible de les rediriger ou de les afficher explicitement avec certains paramètres.

Le jour du transfert au travail, je n'avais pas pensé à vérifier cette sortie.

J’ai voulu reproduire ça en lab — sans toucher au vrai disque du serveur — puis le signaler à OpenSSH (Bugzilla).

Comment j’ai trouvé le problème

1. export d’un dump ;
2. envoi avec scp ;
3. plus assez d’espace sur la destination ;
4. un fichier distant existe quand même, mais pas en entier.

Sans comparer taille / checksum, on peut croire que c’est bon.

Comment j’ai reproduit (lab Docker)

Idée : ne pas saturer / du serveur.
J’ai lancé un conteneur OpenSSH (linuxserver/openssh-server) avec un tmpfs 8 Mo comme dossier d’upload. Comme ça :

• le « disque plein » est isolé dans Docker ;
• on peut vider / recommencer en une commande ;
• le reste de la machine reste intact.

Schéma du lab :

• client : ma machine (scp, OpenSSH 8.9) ;
• serveur : conteneur, port 2222, user charib ;
• destination : upload/ → tmpfs /data limité à 8 Mo ;
• ~1 Mo libre, fichier source 30 Mo.

Étapes (résumé)

1. Source 30 Mo

mkdir -p /tmp/scp-diskfull-repro && cd /tmp/scp-diskfull-repro
dd if=/dev/urandom of=dump_test.sql bs=1M count=30
sha256sum dump_test.sql
ls -lh dump_test.sql

2. Remplir le tmpfs du conteneur (~1 Mo libre)

docker exec scp-diskfull-sshd sh -c '
  rm -f /data/dump_test.sql /data/filler.bin
  avail=$(df -B1 /data | tail -1 | awk "{print \$4}")
  leave=1048576
  fill=$((avail-leave))
  dd if=/dev/zero of=/data/filler.bin bs=4096 count=$((fill/4096)) status=none
  df -h /data
'

3. scp de base (stdout / stderr séparés pour bien voir l’erreur)

scp -P 2222 dump_test.sql charib@127.0.0.1:upload/ \
  >transfer_stdout.log \
  2>transfer_stderr.log
echo "Exit code: $?"

4. Vérifier

ls -lh dump_test.sql
ssh -p 2222 charib@127.0.0.1 \
  'ls -lh upload/dump_test.sql; sha256sum upload/dump_test.sql; df -h upload'

Résultats

Cas simple — leftover partiel

Le ls distant seul trompe : on voit un fichier, on croit que c’est copié.

Cas C — un fichier valide est écrasé

Plus intéressant : que se passe-t-il s’il y avait déjà un dump correct au même chemin ?

1. j’uploade d’abord un petit fichier complet (ex. 512 Ko) → hash OK ;
2. je remplis le tmpfs (~1 Mo libre) en gardant ce fichier ;
3. je relance scp du gros fichier (30 Mo) vers le même nom ;
4. scp échoue (ENOSPC), mais…

Donc ce n’est pas seulement un leftover : un fichier valide a été remplacé par un incomplet. Pour un dump / backup, c’est une vraie perte de données.

Rapport Bugzilla

J’ai ouvert un rapport sur Bugzilla — Portable OpenSSH (component scp), avec versions, steps, tailles, SHA-256, et le lien vers le bug 1703.

Titre plutôt dans cet esprit :
scp leaves incomplete destination file after failed transfer due to insufficient disk space
(et le cas C renforce : overwrites an existing valid file with a truncated one).

Bonnes pratiques

1. ne pas se fier à « le fichier existe » ;
2. comparer taille source ↔ dest ;
3. SHA-256 des deux côtés ;
4. si partiel → supprimer (ou mieux : ne jamais écraser en place) ;
5. préférer rsync (souvent temp + rename).

En bref

• Problème vu sur un dump + espace disque.
  
• Lab Docker + tmpfs : sûr, reproductible, sans casser le serveur.
  
• Leftover partiel et écrasement d’un fichier déjà valide.
  
• Signalé à OpenSSH (lien bug 1703).

#scp #openssh #testing #enospc #docker #opensource #bugreport

Auteur — Gabriel Charib
Functional Analyst / QA Tester· notes techniques & projets

← Tous les articles · Portfolio · LinkedIn

Contribution : wLaunchELF

PR mergée dans ps2homebrew/wLaunchELF :

fix: clearer color labels in Screen Settings (Fixes #128)

Dans Screen Settings, les couleurs 4 à 8 s’appelaient Normal, Graph1… Graph4. Peu clair : on ne voyait pas ce que chaque couleur changeait dans l’UI.

Couleurs 1–3 inchangées (Backgr, Frames, Select).

Côté code : nouvelles chaînes dans lang.h, mapping mis à jour dans config.c.
Pas de changement des valeurs de couleur, des clés CNF (GUI_Col_*), ni de la logique du file browser.

Mergée le 10 juin 2026 dans master.

Pourquoi un serveur de build ?

Compiler le SDK PS2 sur un Mac, ça alourdit vite la machine. J’ai donc monté un serveur auto-hébergé avec l’OpenPS2SDK : édition / git sur le Mac, build sur le serveur.

Mac → Serveur OpenPS2SDK → Build ELF → Émulateur → PS2 réelle

Comment je teste

1. Émulateur — itérations rapides (lancer l’ELF, vérifier l’UI / les labels).
2. PlayStation 2 physique — validation finale sur console réelle.

L’émulateur évite de brancher la PS2 à chaque micro-changement ; la console confirme que ça tient vraiment en conditions réelles.

En bref

• Contribution upstream : labels de couleurs plus lisibles dans wLaunchELF.
• Infra perso : serveur + OpenPS2SDK pour compiler hors du Mac.
• Double test : émulateur au quotidien, PS2 pour le go final.

Lien PR : https://github.com/ps2homebrew/wLaunchELF/pull/145

Lire aussi

→ Hackathon 2026 : faire du neuf avec de l'ancien

#ps2 #homebrew #wlaunchelf #opensource #openps2sdk #selfhosted

Auteur — Gabriel Charib
Functional Analyst / QA Tester· notes techniques & projets

← Tous les articles · Portfolio · LinkedIn