Bug 196996

Pour ce bug, j'ai crée un fichier comme une partition en linux.

touch /tmp/fsfile
mkdir /tmp/fsdir/
dd if=/dev/zero of=/tmp/fsfile bs=1k count=3000
/sbin/mke2fs -m 0 -i 2000 /tmp/fsfile
mount -o loop -t ext2 /tmp/fsfile /tmp/fsdir/

Après avoir créer la partition, j'ai enregistrer un ogg de 9 mo sur la partition. J'ai tout de suite remarqué l'erreur.

Mais ma curiosité sans limite m'a poussé à regarder dans le code où l'erreur s'était produise.

1. J'ai donc chercher par la source de départ, l'option "Save Link to Disk..." qui m'a conduit à un fichier DTD (définition des chaîne de caractères comme une entité).
2. J'ai recherché l'entité et j'ai trouvé le fichier qui gère les menus contextuels pour Firebird (XPFE).
3. Ensuite, le menu appelle la fonction saveLink().
4. La fonction saveLink() appelle la fonction saveURL().
5. La fonction saveURL() crée la classe nsHeaderSniffer.
6. Ensuite, la classe nsHeaderSniffer() crée un component nsURIChecker et devient un membre de ce component c++ (XPCOM). Puisque le nsHeaderSniffer est lié au component XPCOM, la classe javascript redéfinit des fonctions qui seront utilisés par le component plus tard. C'est ainsi que le component C++ agit selon le code javascript. C'est une utilisation concrète du patron "Template Method pattern" en utilisant deux langages différents.
7. On peut voir plus loin dans le code javascript, la fonction get PromptService() qui permet d'afficher la boîte qui demande où enregistrer le fichier.

Bon je crois avoir découvert une autre piste en essayant de nouveau la fonction "Save Link to Disk...". Je vais rechercher la phrase "There is not enough room on the disk to save".

1. La chaîne est définie dans le fichier nsWebBrowserPersist.properties. Elle fait référence à la variable diskFull.
2. La variable est déclaré dans la fonction nsWebBrowserPersist::SendErrorStatusChange
3. Bon je viens de rechercher webbrowserpersist dans le fichier contentAreaUtils.js et que vois-je? La fonction makeWebBrowserPersist().
4. La fonction makeWebBrowserPersist() est appelé par la fonction foundHeaderInfo().
5. Et qui utilise cette fonction? notre classe nsHeaderSniffer (en référence)!!! Ce qui fait que le paramètre aCallback et la variable/méthode mCallback sont très importants.
6. La fonction mCallback est à la toute fin de onStopRequest (qui est une redéfinition de la fonction onStopRequest du component XPCOM).

Ce qui fait que la fonction foundHeaderInfo() est celle qui gère la boite de dialogue et effectue l'appel vers la fonction persist.saveURI().

1. saveURI appelle saveURIInternal
2. Ah Ah! manque de mémoire d'après le commentaire // Disaster - can't write out the bytes - disk full / permission?
3. Après un "disaster", la fonction EndDownload est censé nettoyer le tout, soit selon la condition suivante : if (NS_FAILED(aResult) && (mPersistFlags & PERSIST_FLAGS_CLEANUP_ON_FAILURE))
4. Ce qui veut dire qu'on doit poser la question suivante, est-ce que NS_FAILED() retourne vrai lorsqu'il s'agit d'un NS_ERROR_FILE_DISK_FULL (10) ou d'un case NS_ERROR_FILE_NO_DEVICE_SPACE (16). Et est-ce que mPersistFlags & PERSIST_FLAGS_CLEANUP_ON_FAILURE (8192) retourne une valeur non nulle?
5. À cet instant, quelle est la valeur de mPersistFlags? À l'initialisation de la classe, mPersistFlags à la valeur suivante: PERSIST_FLAGS_NO_CONVERSION || PERSIST_FLAGS_REPLACE_EXISTING_FILES
6. Dans saveURI() on rajoute PERSIST_FLAGS_FAIL_ON_BROKEN_LINKS
7. Si on se fie à l'outil de recherche de lxr, on peut voir que le flag n'est jamais utilisé: PERSIST_FLAGS_CLEANUP_ON_FAILURE

En conclusion, on test un un flag qui n'est jamais utilisé. Le nettoyage ne se fait donc pas.