Lorsqu'un PC modifie un fichier, il supprimait-il le fichier d'origine?
Si code.txt (ou quel que soit le fichier) édité et enregistré, j'ai deux idées sur la manière dont un PC gérerait le processus:
Le PC supprime
code.txtcomplètement et fait un nouveaucode.txt(version éditée) à partir de zéro.Le PC modifie une partie de HEX de
code.txt. Donc, aucune suppression ne se produit.
Quelle idée représente comment les ordinateurs fonctionnent?
Pourrait être soit - cela dépend de l'éditeur de texte utilisé.
Le concept d'un "fichier texte" n'est pas intégré à des ordinateurs - chaque système d'exploitation peut gérer des fichiers différemment, et chaque éditeur de texte peut utiliser ces fichiers différemment.
En pratique, vous trouverez des éditeurs de texte qui ont les deux mécanismes. Pratiquement tous les systèmes d'exploitation Autoriser écrasement direct d'un contenu d'un fichier existant, des éditeurs simples, tels que le bloc-notes, demandent généralement à l'OS d'écrire directement dans le fichier d'origine, car c'est le plus facile à mettre en œuvre - mais risqué si vous perdez Puissance moyenne-écriture. Donc, pour des raisons de fiabilité, de nombreux éditeurs délibérément Enregistrez les données mises à jour dans un nouveau fichier et supprimez l'original.
(Je pense que les mises à jour sur place sont plus courantes chez les éditeurs hexadécimaux, où la plupart des modifications n'insirent pas/suppriment les octets mais ne modifient que des emplacements existants, un fichier de réécriture complet n'est donc pas nécessaire.)
Il y a même un troisième mode d'opération - l'éditeur peut d'abord effectuer une copie de sauvegarde de l'ancien fichier, alors écrire directement de nouvelles données dans le fichier.
Il aussi dépend du système de fichiers qui conserve le fichier. Avec la plupart des systèmes de fichiers traditionnels, si un programme demande à écrire dans un fichier existant, le système de fichiers remplacera simplement les données anciennes en place.
Toutefois, certains systèmes de fichiers DO Travailler dans le mode "Copier-on-écriture", dans lequel toutes les nouvelles données sont toujours écrites dans un emplacement différent, que le programme le souhaite ou non. Encore une fois, cela a l'avantage possible de la fiabilité accrue, car un changement interrompu peut être entièrement rétabli.
Dans certains systèmes de fichiers (tels que BTRFS ou EXT4), il s'agit d'une fonctionnalité facultative; Dans d'autres (par exemple, les systèmes de fichiers structurés de log), il fait partie de la conception de base.
Depuis que vous parlez de "enregistrer le fichier", le fichier ne sera pas modifié en place sur le disque.
Avec un fichier dans un système de fichiers habituel, il y a deux choses à prendre en compte. Il y a l'entrée de répertoire, puis il y a les données de fichier réelles quelque part sur le disque.
Lorsque vous modifiez un fichier dans un éditeur normal, il chargera les données de fichier dans la RAM et toute modification aura lieu sur cette copie des données. Ensuite, lorsque vous enregistrez le fichier, il y a essentiellement deux options:
Option 1: Le fichier d'origine est renommé, la saisie de répertoire d'origine et les données d'origine resteront sur le disque. La renommée peut par exemple modifier le suffixe de fichier à .bak (Supprimer tout précédent .bak Fichier, généralement). Ensuite, un nouveau fichier est créé et les données de la mémoire sont écrites là-bas.
Option 2: L'entrée d'annuaire d'origine est modifiée afin que le fichier soit tronqué à 0 longueur. La zone sur le disque utilisé pour les données de fichier sera marquée comme inutilisée, mais l'ancien contenu du fichier restera sur le disque jusqu'à ce qu'ils soient écrasés. Ensuite, de nouvelles données sont écrites. Dans ce cas, la saisie du répertoire reste, mais les données qu'il pointaient est modifiée.
Il existe quelques variations possibles, un être commun, les données modifiées sont d'abord stockées au fichier temporaire, de sorte que votre ordinateur se bloque à ce stade, le fichier d'origine ne sera probablement pas endommagé. Ensuite, le fichier d'origine est supprimé et le nouveau fichier renommé avec le nom correct. Ou, le fichier d'origine pourrait simplement être supprimé avant d'écrire le nouveau.
Votre théorie 1 est donc proche de la plupart des éditeurs.
Ensuite, il y a des cas particuliers. Le plus évident est un éditeur de disque, qui permet de lire et de remplacer les octets directement sur le disque. Un autre pourrait être un fichier de base de données, où des enregistrements peuvent être une taille fixe, il est donc facile de remplacer un enregistrement. Mais les données ne peuvent pas être annexées au milieu d'un fichier et, partant, modifier des fichiers texte ou tout autre fichier lorsque la longueur des données au milieu du fichier change généralement, ces astuces ne peuvent pas vraiment être utilisées.
Votre théorie 2 est donc possible dans certains cas, mais des éditeurs de texte normaux et de tels autres ne le font pas.
Historiquement, les lecteurs étaient directement contrôlés par le système d'exploitation, qui contrôlait à son tour par l'application. Dans ce contexte, la théorie 2 était la principale façon de travailler. Le système d'exploitation a spécifié A physique Emplacement pour mettre des données et disposait de tout contrôle sur ce processus. En conséquence, les systèmes de fichiers précoces ont eu une table "Basse Secteur", une fois vos données perdues, l'ordinateur pourrait vous dire que les données ont été perdues et marquez le secteur comme inutilisable pour éviter plus de perte de données. Les analyses de disque et la défragmentation ont été l'ordre de la journée.
Cependant, après le tournant du siècle, nous avons déménagé à LBA, alors maintenant que le système d'exploitation ferait simplement référence au bloc "logique" qu'il souhaitait lire ou écrire à. Le disque dur lui-même avait maintenant l'intelligence à mélanger les données derrière le dos du système d'exploitation sans qu'il remarque. Cela signifiait une meilleure fiabilité, car les secteurs qui n'ont pas vérifié peuvent simplement être déplacés vers un nouvel emplacement physique sans affecter la connaissance du système d'exploitation où se trouvait ces données.
Dans le matériel moderne, les lecteurs de disque "Platter" qui viennent généralement écraser ce qui y était auparavant avec les nouvelles données entrantes et éventuellement remapituser la LBA si le secteur semble ne pas conserver les données (le secteur est endommagé ou usé). Les lecteurs "Flash" effacent généralement les anciennes cellules, puis écrivent des données sur de nouvelles cellules, un processus appelé nivellement à l'usure.
Dans les deux cas, cela est possible car il y a toujours une capacité non utilisée au-delà de la valeur rapportée. Cette surflèvement permet à la volonté d'avoir une vie plus utilisable plus longue que la technologie plutôt peu fiable de la technologie du siècle précédent. Le mode LBA permet au support physique d'être résumé du système d'exploitation afin que le lecteur lui-même puisse prendre toutes les mesures que le lecteur pense être nécessaire pour prévenir la perte de données.
Au niveau de l'application, vous ouvrez généralement un fichier en mode "Ecript", qui indique au système d'exploitation d'effacer le fichier ("Supprimer" le contenu, mais pas le fichier lui-même), puis écrivez de nouvelles données. Tout cela est tamponné au niveau du système d'exploitation, puis "rincé" sur le lecteur, ce qui rend les modifications demandées.
Compte tenu de cette information, la théorie 1 est ce qui se produit techniquement au niveau de la programmation de l'application, au moins par défaut, car il existe également un mode "écriture avec append" afin d'éviter de nettoyer le contenu du fichier. Le système d'exploitation lui-même présentera les modifications à apporter davantage à la théorie 2, mais abstraite via LBA. Le lecteur lui-même fera probablement quelque chose qui est un mélange de théorie 1 et de théorie 2.
Ouais. C'est compliqué et très partiel-fabricant/développeur d'exploitation/développeur d'applications dépendant. Cependant, toute cette complexité vise à rendre le stockage de données plus fiable tout en améliorant l'utilisation de l'alimentation/la durée de vie de la batterie.
Dépend. Afaik Microsoft Word, lors de la sauvegarde .doc (ne pas .docx) Les fichiers avec sauvegarde rapide Options activées, ajoute des modifications apportées au document depuis la dernière sauvegarde du fichier existant.
Réponse courte
Dépend fortement de votre éditeur, sous-jacents logiciels/pilotes sous-jacents, stockage.
Réponse paranoïaque
Peut être récupérable à moins que vous l'enlève de manière permanente.
Longue réponse
Il y a des informations manquantes dans votre question (logiciels, matériel, etc.), au lieu de me répondre, je vous aiderai à répondre à votre question vous-même.
Cela dépend quelques facteurs:
Editeur: Si le logiciel éditeur remplace les blocs du même fichier, il May Être réécrit. Et cela peut également être dépendant des paramètres de l'éditeur et des types de fichiers. Notez que le mot peut a été fait en italique. Même lorsque l'éditeur réécrit le fichier, il peut toujours rester intact (lire les points suivants).
Subscripteur sous-jacent/Système de fichiers/Système de fichiers: Fichier restera intact s'il existe d'autres logiciels/pilotes en dessous qui protègent le fichier initial d'être écrasé. Ces types de logiciels incluent les systèmes de versions, les disques différentiels virtuels, certains logiciels de sauvegarde. Un exemple est GIT , qui conservera les blocs de fichiers d'origine et créera un nouveau fichier contenant les blocs modifiés.
Stockage:
Le stockage lui-même peut écrire des blocs modifiés sur un fichier nouveau Secteur et marquer de vieux blocs comme "libre". Ensuite, le fichier restera physiquement sur le stockage (et est recouvrable), sauf s'il est écrasé par un autre fichier. L'exemple est moderne SSD Stockage, qui peut le faire sur un niveau matériel.
Il existe des moyens de récupérer des données à partir d'un disques magnétiques de disque dur mécanique typiques, même lorsque les données étaient écrasées. Et il y a des entreprises spécialisées.
Donc, si vous souhaitez avoir une réponse concrète si votre fichier sera supprimé ou non, vous devez également indiquer quel éditeur, logiciel de sauvegarde/VCS/matériel et de stockage que vous utilisez. Si j'ai manqué un point, n'hésitez pas à modifier la réponse.
Comment vous assurer que le fichier supprimé est effectivement supprimé du stockage?
C'est probablement la prochaine question que vous allez vous interroger. Eh bien, il existe de nombreuses solutions logicielles/matériels. Étant donné que SuperUserer n'est pas pour la promotion de logiciels/matériels, au lieu de dire des noms, je vous dirai comment les trouver: recherchez des mots-clés "Supprimer définitivement le fichier". Pour plus de correspondances exactes, mentionnez votre système d'exploitation, votre type de disque dur ou d'autres informations que vous avez.
Un comportement que personne n'a déjà mentionné est un comportement pertinent de certaines versions des systèmes d'exploitation MS Windows est également liée au système de fichiers utilisé.
Le comportement fonctionne comme ceci: lorsque vous renommez ou supprimez un fichier, si vous créez (recréer) un fichier (nouveau) avec le même nom dans les 15 secondes suivant la suppression du fichier d'origine (ou renommé), la date de création/TimeStamp est copié à partir du fichier d'origine. Essentiellement, le nouveau fichier "devient" le fichier ancien/original.
Dans ce cas, cela n'a pas d'importance si l'application enregistre les modifications apportées au fichier par votre méthode n ° 1: Faire un nouveau fichier avec le même nom ou par votre méthode n ° 2: édition/mise à jour du fichier en place (fichier non supprimé). De toute façon, le fichier final regarde dans (presque) à tous égards, comme le fichier d'origine. La seule chose est que cela occupera probablement différents espaces d'entraînement physique (clusters/secteurs) et la saisie du répertoire pour le fichier sera probablement dans un emplacement différent.
Comme je l'ai dit, il s'agit d'un comportement de certaines versions de MS Windows/Systèmes de fichiers. Je ne sais pas quelle version de Windows et quel système de fichiers a démarré et s'il reste le comportement de versions plus récentes. Si je devais deviner, je dirais que cela a été introduit sur Windows NT et Windows XP et est toujours le comportement de Windows 10, et (toujours une supposition), le comportement nécessite une FAT32 ou des NTFS ( et peut-être plus récent) Système de fichiers.
2 n'est pas impossible, mais c'est stupide pour diverses raisons.
Un éditeur de fichiers texte bien écrit:
- Écrivez un fichier avec un nom différent et le nouveau contenu. Si l'original était
myfile.txt, le nouveau pourrait êtremyfile.txt.new - Fourni 1. a réussi, renommez l'original à un fichier de sauvegarde, dites
myfile.txt~ - Renommez le nouveau fichier au nom d'origine
myfile.txt - Si tout a réussi, supprimez le fichier de sauvegarde. De nombreux éditeurs le laissent quand même, alors l'utilisateur peut récupérer s'il travaille bientôt sur ce qu'il/elle a fait avec l'éditeur n'était pas ce qu'il/elle voulait faire.
Si l'ordinateur se bloque ou fonctionne hors de l'espace sur le disque au cours de ce qui précède, il n'y a pas une situation où les nouveaux et les nouveaux fichiers sont perdus ou partiellement enregistrés.
En règle générale, un ordinateur allouera la mémoire dans laquelle le fichier d'origine réside comme "supprimé", mais tout cela signifie que cela ne s'affiche plus dans votre navigateur de fichiers et les cellules de la mémoire où il a été écrit sont autorisés. être écrasé à l'avenir.
Quant à savoir si le nouveau fichier est écrit au même endroit est à un certain nombre de facteurs, principalement le logiciel que vous utilisez et comment il est conçu pour utiliser la mémoire.