Nous avons ici une discussion intéressante sur la suppression de fichiers sur les appareils iOS. La question était: si je supprime un fichier à l'aide de NSFileManager, que se passe-t-il sous le capot?
Ma compréhension est que la suppression est effectuée en supprimant l'entrée de fichier correspondante de la table du système de fichiers.
L'argument du compteur est qu'un descripteur de fichier reste en quelque sorte et seul un indicateur est défini qui marque le fichier comme supprimé. Si l'utilisateur avait un accès root sur l'appareil iOS, il pourrait potentiellement réinitialiser cet indicateur et récupérer le contenu du fichier.
Dans les deux cas, nous convenons que le contenu réel du fichier ne sera pas écrasé et que les octets simples existent toujours sur la mémoire flash / le disque jusqu'à ce que le bloc soit occupé par un autre fichier.
L'idée est maintenant: si la deuxième version est vraie, nous pourrions écraser le fichier avec un contenu d'un octet avant la suppression (même si cet octet est écrit à un nouvel emplacement sur le lecteur flash sans écraser réellement l'ancien contenu). Si le fichier est récupéré, seul le contenu écrasé d'un octet est disponible.
Notez que nous ne parlons pas d'une analyse médico-légale du lecteur flash qui pourrait peut-être récupérer le contenu du fichier d'origine.
Donc, pour récapituler:
- Comment la suppression d'un fichier sur iOS fonctionne-t-elle en interne?
- L'approche par écrasement empêche-t-elle la suppression?