Если code.txt (или любой другой файл) отредактирован и сохранен, у меня есть две идеи о том, как ПК будет обрабатывать процесс:
ПК полностью удаляет code.txt и создает новый code.txt (отредактированная версия) с нуля.
ПК редактирует часть шестнадцатеричного code.txt . Таким образом, удаление не происходит.
Какая идея представляет, как работают компьютеры?
Может быть либо - это зависит от используемого текстового редактора.
Понятие «текстовый файл» не встроено в компьютеры - каждая операционная система может по-разному управлять файлами, и каждый текстовый редактор может использовать эти файлы по-своему.
На практике вы найдете текстовые редакторы, которые имеют оба механизма. Практически все операционные системы допускают прямую перезапись содержимого существующего файла, поэтому простые редакторы, такие как «Блокнот», обычно просто просят ОС записать непосредственно в исходный файл, что проще всего реализовать - но рискованно, если вы теряете мощность при записи в середине. Поэтому из соображений надежности многие редакторы намеренно сохраняют обновленные данные в новом файле и удаляют исходные.
(Я думаю, что обновления на месте более распространены среди шестнадцатеричных редакторов, где большинство правок не вставляют / удаляют байты, а только меняют существующие местоположения, поэтому полный файл перезаписи не требуется.)
Существует даже третий режим работы - редактор может сначала сделать резервную копию старого файла, а затем непосредственно записать новые данные в файл.
Это также зависит от файловой системы, которая хранит файл. В большинстве традиционных файловых систем, если программа запрашивает запись в существующий файл, файловая система просто перезаписывает старые данные на месте.
Тем не менее, некоторые файловые системы работают в режиме «копирование при записи», где все новые данные всегда записываются в другое место, хочет ли программа или нет. Опять же, это имеет возможное преимущество повышенной надежности, потому что прерванное изменение может быть полностью отменено.
В некоторых файловых системах (таких как Btrfs или ext4) это дополнительная функция; в других (например, файловые системы с лог-структурой) это является частью структуры ядра.
Поскольку вы говорите о "сохранении файла", то файл не будет редактироваться на месте на диске.
С файлом в обычной файловой системе нужно учитывать две вещи. Есть запись в каталоге, а затем где-то на диске есть фактические данные файла.
Когда вы редактируете файл в обычном редакторе, он загружает данные файла в оперативную память, и любое редактирование будет происходить только с этой копией данных. Затем, когда вы сохраняете файл, есть в основном два варианта:
Вариант 1: исходный файл переименовывается, поэтому и исходная запись каталога, и исходные данные останутся на диске. Например, переименование может изменить суффикс файла на .bak (обычно удаляя любой предыдущий файл .bak ). Затем создается новый файл и данные из памяти записываются туда.
Вариант 2: исходная запись каталога изменяется, поэтому файл усекается до длины 0. Область на диске, используемая для данных файла, будет помечена как неиспользуемая, но содержимое старого файла будет оставаться на диске до тех пор, пока оно не будет перезаписано. Затем новые данные пишутся. В этом случае запись каталога остается, просто изменяются данные, на которые она указывает.
Существует несколько возможных вариаций, как правило, когда отредактированные данные сначала сохраняются во временном файле, поэтому в случае сбоя компьютера в этот момент исходный файл, скорее всего, не будет поврежден. Затем исходный файл удаляется, а новый файл переименовывается с правильным именем. Или исходный файл может быть просто удален перед записью нового.
Итак, ваша теория 1 близка к тому, что делает большинство редакторов.
Тогда есть особые случаи. Наиболее очевидным из них является дисковый редактор, который позволяет читать и перезаписывать байты непосредственно на диске. Другим может быть файл базы данных, где записи могут иметь фиксированный размер, поэтому легко перезаписать запись. Но данные не могут быть добавлены в середине файла, и поэтому для редактирования текстовых файлов или любых других файлов, в которых длина данных в середине файла обычно изменяется, эти приемы не могут быть использованы на самом деле.
Так что ваша теория 2 возможна в некоторых случаях, но обычные текстовые редакторы и тому подобное не делают этого.
Исторически накопители напрямую контролировались ОС, которая в свою очередь контролировалась приложением. В этом контексте теория 2 была основным способом работы ПК. ОС указала физическое местоположение для размещения данных и полностью контролировала этот процесс. В результате в ранних файловых системах была таблица "плохих секторов", поэтому после потери ваших данных компьютер мог сообщить вам, что данные были потеряны, и пометить сектор как непригодный для предотвращения дальнейшей потери данных. Сканирование диска и дефрагментация были в порядке дня.
Однако по прошествии столетия мы перешли на LBA, поэтому теперь ОС будет просто ссылаться на "логический" блок, который она хочет прочитать или записать. У самого жесткого диска теперь был интеллект, чтобы перетасовывать данные за спиной ОС, не замечая этого. Это означало повышение надежности, поскольку сектора, которые не удалось проверить, можно было просто переместить в новое физическое местоположение, не влияя на знание операционной системы о том, где находятся эти данные.
В современном оборудовании дисководы "platter" обычно просто перезаписывают то, что было раньше, новыми входящими данными и, при желании, переназначают LBA, если сектор выглядит так, как будто он не сохраняет данные (сектор поврежден или изношен). Флэш-накопители обычно стирают старые ячейки, а затем записывают данные в новые ячейки, процесс, известный как выравнивание износа.
В обоих случаях это возможно, потому что всегда есть неиспользованная емкость сверх сообщенного значения. Такое сверхпредоставление позволяет накопителю работать дольше, чем довольно ненадежная технология предыдущего века. Режим LBA позволяет абстрагировать физический носитель от ОС, чтобы сам диск мог принимать любые меры, которые он считает необходимыми для предотвращения потери данных.
На уровне приложения вы обычно открываете файл в режиме "ЗАПИСЬ", который сообщает ОС очистить файл ("удалить" содержимое, но не сам файл), а затем записать новые данные. Все это буферизируется на уровне ОС, затем "сбрасывается" на диск, что вносит запрошенные изменения.
Учитывая эту информацию, Теория 1 - это то, что технически происходит на уровне прикладного программирования, по крайней мере, по умолчанию, поскольку существует также режим "записи с добавлением", чтобы избежать очистки содержимого файла. Сама ОС представит изменения, которые будут сделаны больше как Теория 2, но абстрагированы через LBA. Тогда сам диск, вероятно, сделает что-то, что является смесью теории 1 и теории 2.
Ага. Это сложно, и очень зависит от производителя /OS-разработчика / приложения-разработчика. Однако вся эта сложность направлена на то, чтобы сделать хранение данных более надежным при одновременном улучшении энергопотребления / времени автономной работы.
Зависит. AFAIK Microsoft Word, при сохранении файлов .doc (не .docx) с включенными параметрами быстрого сохранения , добавляет изменения, внесенные в документ с момента последнего сохранения существующего файла.
Надеюсь, это не излишне, немного дополнительной информации / фона.
ПК обычно не имеет большого контроля над тем, как редактируется файл, это приложение, которое делает это.
Несколько примеров того, как некоторые приложения могут обрабатывать редактирование:
Блокнот загружает весь документ в память, а затем сохраняет все это поверх исходного документа (или нового, который вы укажете).
Почти все другие небольшие редакторы сохраняют "новый" файл при редактировании, а затем копируют его поверх исходного документа, удаляя его при "сохранении".
Большие редакторы документов, которые вы можете использовать для редактирования книги, как правило, читают / изменяют раздел документа, потому что они могут редактировать документы больше памяти. Они могут на самом деле редактировать документ "На месте". Они могут переписать одну страницу, а остальные оставить в покое. Они часто имеют более сложное индексированное представление на диске, чем простой файл .txt, чтобы разрешить такое поведение.
Крупные редакторы могут также просто сохранять временные файлы с "обновлениями" в исходном документе. Когда вы сделаете окончательное сохранение, он может объединить их все и переписать ваш документ.
Большинство редакторов можно настроить так, чтобы оставить существующую версию без изменений и создать новую с вашими изменениями (сохранить старые версии).
Что касается части вашего вопроса относительно того, что делает "ПК", некоторые операционные системы будут помнить каждую версию файла и всегда создавать новую. Это довольно редко в наши дни, но я помню старые «мини-компьютеры» (то, что мы теперь называем мэйнфреймами), в конце каждого файла была версия, например, «File.text.1», и она добавлялась к версии каждый раз, когда вы отредактировал это. Такое поведение лучше бы применить к чему-то вроде ленточного накопителя или компакт-диска, где перезапись старой версии была абсолютно непрактичной.
Одно поведение, которое еще никто не упомянул, - это соответствующее поведение некоторых версий операционных систем MS Windows, также связанное с используемой файловой системой.
Поведение работает следующим образом: когда вы переименовываете или удаляете файл, если вы создаете (заново создаете) (новый) файл с тем же именем в течение 15 секунд после того, как исходный файл был удален (или переименован), дата создания / метка времени копируется из исходного файла. По сути, новый файл "становится" старым / оригинальным файлом.
В этом случае действительно не имеет значения, сохраняет ли приложение изменения в файле вашим методом # 1: создаёт новый файл с тем же именем или вашим методом # 2: редактирует / обновляет файл на месте (файл не удаляется). В любом случае, окончательный файл выглядит (почти) во всех отношениях, как исходный файл. Единственное, что он, скорее всего, будет занимать другое физическое дисковое пространство (кластеры / сектора), и запись каталога для файла, вероятно, будет находиться в другом месте.
Как я уже сказал, это поведение некоторых версий MS Windows/ файловых систем. Я не знаю, с какой версией Windows и с какой файловой системы это началось, и по-прежнему ли это поведение последних версий. Если бы мне пришлось угадывать, я бы сказал, что это было введено в Windows NT и Windows XP и все еще является поведением Windows 10, и (все еще предположение) поведение требует файловой системы Fat32 или NTFS (и, возможно, более новой).
2 не невозможно, но это глупо по разным причинам.
Хорошо написанный редактор текстовых файлов:
myfile.txt , новым может быть myfile.txt.newmyfile.txt~myfile.txtЕсли компьютер выходит из строя или не хватает места на диске во время вышеуказанного, не существует ситуации, когда старые и новые файлы будут потеряны или сохранены только частично.
Вообще говоря, компьютер будет выделять память, в которой находится исходный файл, как «удаленный», но все это действительно означает, что он больше не будет отображаться в вашем файловом браузере, и ячейки в памяти, где он был записан, разрешены. быть перезаписано в будущем.
Вопрос о том, записан ли новый файл в одно и то же место, зависит от ряда факторов, в первую очередь от программного обеспечения, которое вы используете, и от того, как оно предназначено для использования памяти.
Сильно зависит от вашего редактора, базового программного обеспечения / драйверов, хранилища.
Может быть восстановлено, если вы не удалите его навсегда.
В вашем вопросе отсутствует информация (программное обеспечение, оборудование и т.д.), Поэтому вместо ответа на вопрос я сам помогу вам ответить на ваш вопрос.
Это зависит от нескольких факторов:
Редактор . Если программное обеспечение редактора заменяет блоки одного и того же файла, оно может быть переписано. И это также может зависеть от настроек редактора и типов файлов. Обратите внимание, что слово « май» было выделено курсивом. Даже когда редактор переписывает файл, он все равно может оставаться нетронутым (см. Следующие пункты).
Базовое программное обеспечение / драйверы / файловая система: файл останется нетронутым, если под ним находятся другие программы / драйверы, которые защищают исходный файл от перезаписи. К таким типам программного обеспечения относятся системы контроля версий, виртуальные дифференциальные диски, некоторые программы резервного копирования. Примером является Git, который сохранит исходные блоки файлов и создаст новый файл, содержащий измененные блоки.
Хранение:
Само хранилище может записывать измененные блоки в новый сектор и помечать старые блоки как "свободные". Тогда файл физически останется в хранилище (и будет восстановлен), если он не будет перезаписан другим файлом. Примером является современное хранилище SSD, которое может делать это на аппаратном уровне.
Существуют способы восстановления данных с обычных механических жестких дисков, даже если они были перезаписаны . И в этом есть специализированные компании.
Поэтому, если вы хотите получить конкретный ответ, будет ли ваш файл удален или нет, вы также должны указать, какой редактор, программное обеспечение / оборудование для резервного копирования / VCS и хранилище вы используете. Если я пропустил какой-либо пункт, не стесняйтесь редактировать ответ.
Это, вероятно, следующий вопрос, который вы будете задавать себе. Ну, есть много программных / аппаратных решений. Поскольку SuperUser не предназначен для продвижения программного / аппаратного обеспечения, вместо того, чтобы сообщать имена, я расскажу вам, как их найти: выполните поиск по ключевым словам "навсегда удалить файл". Для более точного соответствия укажите вашу ОС, тип жесткого диска или другую имеющуюся у вас информацию.