When a PC edits a file, does it delete the original file?
If code.txt (or whatever file) is edited and saved:
[Theory 1] The PC deletes code.txt completely and makes a new code.txt (edited version) from scratch.
[Theory 2] The PC edits part of hex of code.txt. So no delete happens.
Which theory do computers work?
editing
New contributor
add a comment |
If code.txt (or whatever file) is edited and saved:
[Theory 1] The PC deletes code.txt completely and makes a new code.txt (edited version) from scratch.
[Theory 2] The PC edits part of hex of code.txt. So no delete happens.
Which theory do computers work?
editing
New contributor
add a comment |
If code.txt (or whatever file) is edited and saved:
[Theory 1] The PC deletes code.txt completely and makes a new code.txt (edited version) from scratch.
[Theory 2] The PC edits part of hex of code.txt. So no delete happens.
Which theory do computers work?
editing
New contributor
If code.txt (or whatever file) is edited and saved:
[Theory 1] The PC deletes code.txt completely and makes a new code.txt (edited version) from scratch.
[Theory 2] The PC edits part of hex of code.txt. So no delete happens.
Which theory do computers work?
editing
editing
New contributor
New contributor
edited 27 mins ago
chrki
431213
431213
New contributor
asked 16 hours ago
Chess ManChess Man
805
805
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Could be either – it depends on the text editor that was used.
The concept of a 'text file' isn't built into computers – each operating system may manage files differently, and each text editor may use those files differently.
In practice, you'll find text editors which have both mechanisms. Practically all operating systems allow direct overwrite of an existing file's contents, so simple editors such as Notepad usually just ask the OS to write directly into the original file, as that's easiest to implement – but risky if you lose power mid-write. So for reliability reasons, many editors deliberately save the updated data to a new file and delete the original.
(I think in-place updates are more common among hex editors, where most edits don't insert/delete bytes but only change existing locations, so a full rewrite file is not needed.)
There's even a third mode of operation – the editor might first make a backup copy of the old file, then directly write new data into the file.
It also depends on the filesystem which keeps the file. With most traditional filesystems, if a program asks to write to an existing file, the filesystem will just overwrite old data in-place.
However, some filesystems do work in "copy-on-write" mode, where any new data is always written to a different location, whether the program wants it or not. Again, this has the possible advantage of increased reliability because an interrupted change can be fully reverted.
In some filesystems (such as Btrfs or ext4) this is an optional feature; in others (e.g. log-structured filesystems) it is part of the core design.
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
add a comment |
Generally speaking, A computer will allocate the memory where the original file resides as 'deleted', but all this really means is that it won't show up in your file browser anymore, and the cells in the memory where it was written are allowed to be overwritten in future.
As to whether the new file is written into the same place is down to a number of factors, primarily the software you are using and how it is designed to make use of the memory.
New contributor
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Chess Man is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397186%2fwhen-a-pc-edits-a-file-does-it-delete-the-original-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Could be either – it depends on the text editor that was used.
The concept of a 'text file' isn't built into computers – each operating system may manage files differently, and each text editor may use those files differently.
In practice, you'll find text editors which have both mechanisms. Practically all operating systems allow direct overwrite of an existing file's contents, so simple editors such as Notepad usually just ask the OS to write directly into the original file, as that's easiest to implement – but risky if you lose power mid-write. So for reliability reasons, many editors deliberately save the updated data to a new file and delete the original.
(I think in-place updates are more common among hex editors, where most edits don't insert/delete bytes but only change existing locations, so a full rewrite file is not needed.)
There's even a third mode of operation – the editor might first make a backup copy of the old file, then directly write new data into the file.
It also depends on the filesystem which keeps the file. With most traditional filesystems, if a program asks to write to an existing file, the filesystem will just overwrite old data in-place.
However, some filesystems do work in "copy-on-write" mode, where any new data is always written to a different location, whether the program wants it or not. Again, this has the possible advantage of increased reliability because an interrupted change can be fully reverted.
In some filesystems (such as Btrfs or ext4) this is an optional feature; in others (e.g. log-structured filesystems) it is part of the core design.
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
add a comment |
Could be either – it depends on the text editor that was used.
The concept of a 'text file' isn't built into computers – each operating system may manage files differently, and each text editor may use those files differently.
In practice, you'll find text editors which have both mechanisms. Practically all operating systems allow direct overwrite of an existing file's contents, so simple editors such as Notepad usually just ask the OS to write directly into the original file, as that's easiest to implement – but risky if you lose power mid-write. So for reliability reasons, many editors deliberately save the updated data to a new file and delete the original.
(I think in-place updates are more common among hex editors, where most edits don't insert/delete bytes but only change existing locations, so a full rewrite file is not needed.)
There's even a third mode of operation – the editor might first make a backup copy of the old file, then directly write new data into the file.
It also depends on the filesystem which keeps the file. With most traditional filesystems, if a program asks to write to an existing file, the filesystem will just overwrite old data in-place.
However, some filesystems do work in "copy-on-write" mode, where any new data is always written to a different location, whether the program wants it or not. Again, this has the possible advantage of increased reliability because an interrupted change can be fully reverted.
In some filesystems (such as Btrfs or ext4) this is an optional feature; in others (e.g. log-structured filesystems) it is part of the core design.
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
add a comment |
Could be either – it depends on the text editor that was used.
The concept of a 'text file' isn't built into computers – each operating system may manage files differently, and each text editor may use those files differently.
In practice, you'll find text editors which have both mechanisms. Practically all operating systems allow direct overwrite of an existing file's contents, so simple editors such as Notepad usually just ask the OS to write directly into the original file, as that's easiest to implement – but risky if you lose power mid-write. So for reliability reasons, many editors deliberately save the updated data to a new file and delete the original.
(I think in-place updates are more common among hex editors, where most edits don't insert/delete bytes but only change existing locations, so a full rewrite file is not needed.)
There's even a third mode of operation – the editor might first make a backup copy of the old file, then directly write new data into the file.
It also depends on the filesystem which keeps the file. With most traditional filesystems, if a program asks to write to an existing file, the filesystem will just overwrite old data in-place.
However, some filesystems do work in "copy-on-write" mode, where any new data is always written to a different location, whether the program wants it or not. Again, this has the possible advantage of increased reliability because an interrupted change can be fully reverted.
In some filesystems (such as Btrfs or ext4) this is an optional feature; in others (e.g. log-structured filesystems) it is part of the core design.
Could be either – it depends on the text editor that was used.
The concept of a 'text file' isn't built into computers – each operating system may manage files differently, and each text editor may use those files differently.
In practice, you'll find text editors which have both mechanisms. Practically all operating systems allow direct overwrite of an existing file's contents, so simple editors such as Notepad usually just ask the OS to write directly into the original file, as that's easiest to implement – but risky if you lose power mid-write. So for reliability reasons, many editors deliberately save the updated data to a new file and delete the original.
(I think in-place updates are more common among hex editors, where most edits don't insert/delete bytes but only change existing locations, so a full rewrite file is not needed.)
There's even a third mode of operation – the editor might first make a backup copy of the old file, then directly write new data into the file.
It also depends on the filesystem which keeps the file. With most traditional filesystems, if a program asks to write to an existing file, the filesystem will just overwrite old data in-place.
However, some filesystems do work in "copy-on-write" mode, where any new data is always written to a different location, whether the program wants it or not. Again, this has the possible advantage of increased reliability because an interrupted change can be fully reverted.
In some filesystems (such as Btrfs or ext4) this is an optional feature; in others (e.g. log-structured filesystems) it is part of the core design.
edited 9 hours ago
answered 15 hours ago
grawitygrawity
235k36497552
235k36497552
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
add a comment |
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
4
4
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
It's not just on a filesystem level. Flash memory, for example, has to clear a block before it can write to it. So, in practice, it will often write to files simply by writing the new change to a new block, and invalidating it on the old block. By having this sort of thing handled automatically by the device itself, the OS can just use a normal hard drive file system.
– trlkly
14 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
@trlkly: All modern flash memory devices are divided into erase regions which are orders of magnitude larger than a disk sector, and cannot recycle any portion of such a region without erasing all of it. Consequently, if a region contains 32 obsolete sectors worth of data and 224 sectors of useful data, it will have to copy the 224 sectors of useful data somewhere else before it can free up the space from any of the obsolete sectors. Modern operating systems use a "trim" command to indicate disk sectors whose contents can be abandoned if the block they are on gets recycled.
– supercat
12 hours ago
add a comment |
Generally speaking, A computer will allocate the memory where the original file resides as 'deleted', but all this really means is that it won't show up in your file browser anymore, and the cells in the memory where it was written are allowed to be overwritten in future.
As to whether the new file is written into the same place is down to a number of factors, primarily the software you are using and how it is designed to make use of the memory.
New contributor
add a comment |
Generally speaking, A computer will allocate the memory where the original file resides as 'deleted', but all this really means is that it won't show up in your file browser anymore, and the cells in the memory where it was written are allowed to be overwritten in future.
As to whether the new file is written into the same place is down to a number of factors, primarily the software you are using and how it is designed to make use of the memory.
New contributor
add a comment |
Generally speaking, A computer will allocate the memory where the original file resides as 'deleted', but all this really means is that it won't show up in your file browser anymore, and the cells in the memory where it was written are allowed to be overwritten in future.
As to whether the new file is written into the same place is down to a number of factors, primarily the software you are using and how it is designed to make use of the memory.
New contributor
Generally speaking, A computer will allocate the memory where the original file resides as 'deleted', but all this really means is that it won't show up in your file browser anymore, and the cells in the memory where it was written are allowed to be overwritten in future.
As to whether the new file is written into the same place is down to a number of factors, primarily the software you are using and how it is designed to make use of the memory.
New contributor
New contributor
answered 2 hours ago
GigaJoulesGigaJoules
112
112
New contributor
New contributor
add a comment |
add a comment |
Chess Man is a new contributor. Be nice, and check out our Code of Conduct.
Chess Man is a new contributor. Be nice, and check out our Code of Conduct.
Chess Man is a new contributor. Be nice, and check out our Code of Conduct.
Chess Man is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397186%2fwhen-a-pc-edits-a-file-does-it-delete-the-original-file%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown