How to recover files truncated by `>`?
I had a text file hello.txt
which contains about 100 lines.I accidentally deleted all the lines by running echo > hello.txt
Now i want to recover all the 100 lines.Is there any way to recover the lines in that file using terminal commands?
command-line
add a comment |
I had a text file hello.txt
which contains about 100 lines.I accidentally deleted all the lines by running echo > hello.txt
Now i want to recover all the 100 lines.Is there any way to recover the lines in that file using terminal commands?
command-line
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on thehello.txt
file and revert it to a previous version.
– user68186
Jan 9 '14 at 17:34
add a comment |
I had a text file hello.txt
which contains about 100 lines.I accidentally deleted all the lines by running echo > hello.txt
Now i want to recover all the 100 lines.Is there any way to recover the lines in that file using terminal commands?
command-line
I had a text file hello.txt
which contains about 100 lines.I accidentally deleted all the lines by running echo > hello.txt
Now i want to recover all the 100 lines.Is there any way to recover the lines in that file using terminal commands?
command-line
command-line
edited Jan 9 '14 at 17:48
Braiam
52.2k20136222
52.2k20136222
asked Jan 9 '14 at 17:26
Avinash RajAvinash Raj
52.2k41168219
52.2k41168219
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on thehello.txt
file and revert it to a previous version.
– user68186
Jan 9 '14 at 17:34
add a comment |
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on thehello.txt
file and revert it to a previous version.
– user68186
Jan 9 '14 at 17:34
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on the
hello.txt
file and revert it to a previous version.– user68186
Jan 9 '14 at 17:34
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on the
hello.txt
file and revert it to a previous version.– user68186
Jan 9 '14 at 17:34
add a comment |
3 Answers
3
active
oldest
votes
You can not get back the contents. There is no mercy.
But search for backup files. If you are lucky enough there will be a file named hello.txt~
for hello.txt
in the same directory. Those files are usually created by text editors like gedit
or emacs
when you edit a file.
If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,
mv hello.txt~ hello.txt
It is better to have even a part than losing it completely.
i tried to findhello.txt~
file by runningls
command on that directory.Now i can be able to see that,and then move the contents tohello.txt
file.Now it works.
– Avinash Raj
Jan 9 '14 at 18:10
1
Note that backup files are specific to each utility.vim
createsfile.txt~
type of files, and alsofile.txt.swp
type which contains undo-redo history ( see also ).nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.
– Sergiy Kolodyazhnyy
9 hours ago
add a comment |
tl;dr Skip to the end for the working solution.
I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.
I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.
First, remount the filesystem as readonly!. Do this as soon as possible.
sudo mount -o remount,ro /
In my case, I was unable to remount readonly, so...
The mount
command failed. with error mount: / is busy
.
I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.
Per a comment here, I ran telinit 1
which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1
. I recommend the hard power down.
attempt using ext3grep
Following this blog post and this email thread, try using ext3grep
.
However, ext3grep
failed for me. I was only able to recover the truncated file.
attempt using sleuthkit
sleuthkit
is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the /
mount. Again, I recommend hard powering off and then running a LiveCD.
Using this blog post, and this blog post, the instructions are essentially
apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call itINODE_NUMBER
)
- backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
debugfs /dev/disk-device
stats
look for Blocks per group
This is very likely 32768. (call itBLOCKS_PER_GROUP
)
- imap to get the block
imap <$INODE_NUMBER>
remember the block number (call itBLOCK_NUMBER
)
- use
blkls
to copy the blocks to a fileblkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
- manually review and clean up recovered-file using some editor program
But sleuthkit
did not work for me. Only the truncated file was recovered.
attempt using extundelete
From this forum post.
attempt using grep
From this post, grep for some known string in the truncated file. This is the only method that worked for me.
grep -a -A 1000 -F 'some known string'
/dev/disk-device > recovered-file
Surprisingly simple, eh?
add a comment |
Sorry friend, It's impossible...
You can recover deleted files but you can't recover a file with deleted content..
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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
});
}
});
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%2faskubuntu.com%2fquestions%2f403010%2fhow-to-recover-files-truncated-by%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can not get back the contents. There is no mercy.
But search for backup files. If you are lucky enough there will be a file named hello.txt~
for hello.txt
in the same directory. Those files are usually created by text editors like gedit
or emacs
when you edit a file.
If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,
mv hello.txt~ hello.txt
It is better to have even a part than losing it completely.
i tried to findhello.txt~
file by runningls
command on that directory.Now i can be able to see that,and then move the contents tohello.txt
file.Now it works.
– Avinash Raj
Jan 9 '14 at 18:10
1
Note that backup files are specific to each utility.vim
createsfile.txt~
type of files, and alsofile.txt.swp
type which contains undo-redo history ( see also ).nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.
– Sergiy Kolodyazhnyy
9 hours ago
add a comment |
You can not get back the contents. There is no mercy.
But search for backup files. If you are lucky enough there will be a file named hello.txt~
for hello.txt
in the same directory. Those files are usually created by text editors like gedit
or emacs
when you edit a file.
If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,
mv hello.txt~ hello.txt
It is better to have even a part than losing it completely.
i tried to findhello.txt~
file by runningls
command on that directory.Now i can be able to see that,and then move the contents tohello.txt
file.Now it works.
– Avinash Raj
Jan 9 '14 at 18:10
1
Note that backup files are specific to each utility.vim
createsfile.txt~
type of files, and alsofile.txt.swp
type which contains undo-redo history ( see also ).nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.
– Sergiy Kolodyazhnyy
9 hours ago
add a comment |
You can not get back the contents. There is no mercy.
But search for backup files. If you are lucky enough there will be a file named hello.txt~
for hello.txt
in the same directory. Those files are usually created by text editors like gedit
or emacs
when you edit a file.
If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,
mv hello.txt~ hello.txt
It is better to have even a part than losing it completely.
You can not get back the contents. There is no mercy.
But search for backup files. If you are lucky enough there will be a file named hello.txt~
for hello.txt
in the same directory. Those files are usually created by text editors like gedit
or emacs
when you edit a file.
If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,
mv hello.txt~ hello.txt
It is better to have even a part than losing it completely.
answered Jan 9 '14 at 17:41
souravcsouravc
27.3k1377106
27.3k1377106
i tried to findhello.txt~
file by runningls
command on that directory.Now i can be able to see that,and then move the contents tohello.txt
file.Now it works.
– Avinash Raj
Jan 9 '14 at 18:10
1
Note that backup files are specific to each utility.vim
createsfile.txt~
type of files, and alsofile.txt.swp
type which contains undo-redo history ( see also ).nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.
– Sergiy Kolodyazhnyy
9 hours ago
add a comment |
i tried to findhello.txt~
file by runningls
command on that directory.Now i can be able to see that,and then move the contents tohello.txt
file.Now it works.
– Avinash Raj
Jan 9 '14 at 18:10
1
Note that backup files are specific to each utility.vim
createsfile.txt~
type of files, and alsofile.txt.swp
type which contains undo-redo history ( see also ).nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.
– Sergiy Kolodyazhnyy
9 hours ago
i tried to find
hello.txt~
file by running ls
command on that directory.Now i can be able to see that,and then move the contents to hello.txt
file.Now it works.– Avinash Raj
Jan 9 '14 at 18:10
i tried to find
hello.txt~
file by running ls
command on that directory.Now i can be able to see that,and then move the contents to hello.txt
file.Now it works.– Avinash Raj
Jan 9 '14 at 18:10
1
1
Note that backup files are specific to each utility.
vim
creates file.txt~
type of files, and also file.txt.swp
type which contains undo-redo history ( see also ). nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.– Sergiy Kolodyazhnyy
9 hours ago
Note that backup files are specific to each utility.
vim
creates file.txt~
type of files, and also file.txt.swp
type which contains undo-redo history ( see also ). nano
text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection.– Sergiy Kolodyazhnyy
9 hours ago
add a comment |
tl;dr Skip to the end for the working solution.
I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.
I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.
First, remount the filesystem as readonly!. Do this as soon as possible.
sudo mount -o remount,ro /
In my case, I was unable to remount readonly, so...
The mount
command failed. with error mount: / is busy
.
I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.
Per a comment here, I ran telinit 1
which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1
. I recommend the hard power down.
attempt using ext3grep
Following this blog post and this email thread, try using ext3grep
.
However, ext3grep
failed for me. I was only able to recover the truncated file.
attempt using sleuthkit
sleuthkit
is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the /
mount. Again, I recommend hard powering off and then running a LiveCD.
Using this blog post, and this blog post, the instructions are essentially
apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call itINODE_NUMBER
)
- backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
debugfs /dev/disk-device
stats
look for Blocks per group
This is very likely 32768. (call itBLOCKS_PER_GROUP
)
- imap to get the block
imap <$INODE_NUMBER>
remember the block number (call itBLOCK_NUMBER
)
- use
blkls
to copy the blocks to a fileblkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
- manually review and clean up recovered-file using some editor program
But sleuthkit
did not work for me. Only the truncated file was recovered.
attempt using extundelete
From this forum post.
attempt using grep
From this post, grep for some known string in the truncated file. This is the only method that worked for me.
grep -a -A 1000 -F 'some known string'
/dev/disk-device > recovered-file
Surprisingly simple, eh?
add a comment |
tl;dr Skip to the end for the working solution.
I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.
I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.
First, remount the filesystem as readonly!. Do this as soon as possible.
sudo mount -o remount,ro /
In my case, I was unable to remount readonly, so...
The mount
command failed. with error mount: / is busy
.
I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.
Per a comment here, I ran telinit 1
which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1
. I recommend the hard power down.
attempt using ext3grep
Following this blog post and this email thread, try using ext3grep
.
However, ext3grep
failed for me. I was only able to recover the truncated file.
attempt using sleuthkit
sleuthkit
is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the /
mount. Again, I recommend hard powering off and then running a LiveCD.
Using this blog post, and this blog post, the instructions are essentially
apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call itINODE_NUMBER
)
- backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
debugfs /dev/disk-device
stats
look for Blocks per group
This is very likely 32768. (call itBLOCKS_PER_GROUP
)
- imap to get the block
imap <$INODE_NUMBER>
remember the block number (call itBLOCK_NUMBER
)
- use
blkls
to copy the blocks to a fileblkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
- manually review and clean up recovered-file using some editor program
But sleuthkit
did not work for me. Only the truncated file was recovered.
attempt using extundelete
From this forum post.
attempt using grep
From this post, grep for some known string in the truncated file. This is the only method that worked for me.
grep -a -A 1000 -F 'some known string'
/dev/disk-device > recovered-file
Surprisingly simple, eh?
add a comment |
tl;dr Skip to the end for the working solution.
I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.
I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.
First, remount the filesystem as readonly!. Do this as soon as possible.
sudo mount -o remount,ro /
In my case, I was unable to remount readonly, so...
The mount
command failed. with error mount: / is busy
.
I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.
Per a comment here, I ran telinit 1
which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1
. I recommend the hard power down.
attempt using ext3grep
Following this blog post and this email thread, try using ext3grep
.
However, ext3grep
failed for me. I was only able to recover the truncated file.
attempt using sleuthkit
sleuthkit
is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the /
mount. Again, I recommend hard powering off and then running a LiveCD.
Using this blog post, and this blog post, the instructions are essentially
apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call itINODE_NUMBER
)
- backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
debugfs /dev/disk-device
stats
look for Blocks per group
This is very likely 32768. (call itBLOCKS_PER_GROUP
)
- imap to get the block
imap <$INODE_NUMBER>
remember the block number (call itBLOCK_NUMBER
)
- use
blkls
to copy the blocks to a fileblkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
- manually review and clean up recovered-file using some editor program
But sleuthkit
did not work for me. Only the truncated file was recovered.
attempt using extundelete
From this forum post.
attempt using grep
From this post, grep for some known string in the truncated file. This is the only method that worked for me.
grep -a -A 1000 -F 'some known string'
/dev/disk-device > recovered-file
Surprisingly simple, eh?
tl;dr Skip to the end for the working solution.
I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.
I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.
First, remount the filesystem as readonly!. Do this as soon as possible.
sudo mount -o remount,ro /
In my case, I was unable to remount readonly, so...
The mount
command failed. with error mount: / is busy
.
I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.
Per a comment here, I ran telinit 1
which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1
. I recommend the hard power down.
attempt using ext3grep
Following this blog post and this email thread, try using ext3grep
.
However, ext3grep
failed for me. I was only able to recover the truncated file.
attempt using sleuthkit
sleuthkit
is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the /
mount. Again, I recommend hard powering off and then running a LiveCD.
Using this blog post, and this blog post, the instructions are essentially
apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call itINODE_NUMBER
)
- backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
debugfs /dev/disk-device
stats
look for Blocks per group
This is very likely 32768. (call itBLOCKS_PER_GROUP
)
- imap to get the block
imap <$INODE_NUMBER>
remember the block number (call itBLOCK_NUMBER
)
- use
blkls
to copy the blocks to a fileblkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
- manually review and clean up recovered-file using some editor program
But sleuthkit
did not work for me. Only the truncated file was recovered.
attempt using extundelete
From this forum post.
attempt using grep
From this post, grep for some known string in the truncated file. This is the only method that worked for me.
grep -a -A 1000 -F 'some known string'
/dev/disk-device > recovered-file
Surprisingly simple, eh?
edited 10 hours ago
answered Jul 15 '15 at 17:44
JamesThomasMoon1979JamesThomasMoon1979
1567
1567
add a comment |
add a comment |
Sorry friend, It's impossible...
You can recover deleted files but you can't recover a file with deleted content..
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
add a comment |
Sorry friend, It's impossible...
You can recover deleted files but you can't recover a file with deleted content..
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
add a comment |
Sorry friend, It's impossible...
You can recover deleted files but you can't recover a file with deleted content..
Sorry friend, It's impossible...
You can recover deleted files but you can't recover a file with deleted content..
answered Jan 9 '14 at 17:30
MaythuxMaythux
51.4k32171218
51.4k32171218
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
add a comment |
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
1
1
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling.
– GabrielF
Jan 9 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google
– Maythux
Jan 9 '14 at 17:40
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
@Maythux it was possible! See my answer. :-)
– JamesThomasMoon1979
10 hours ago
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f403010%2fhow-to-recover-files-truncated-by%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
This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on the
hello.txt
file and revert it to a previous version.– user68186
Jan 9 '14 at 17:34