Why does photorec keep finding files after I have filled the disk free space as root?Retrieve data from free...
How to assess the long-term stability of a college as part of a job search
Strange "DuckDuckGo dork" takes me to random website
Macro expansion inside href
TikZ graph edges not drawn nicely
How to deal with possible delayed baggage?
Saint abbreviation
Can I announce prefix 161.117.25.0/24 even though I don't have all of /24 IPs
Is there a lava-breathing lizard creature (that could be worshipped by a cult) in 5e?
Which communication protocol is used in AdLib sound card?
Do "fields" always combine by addition?
Has any human ever had the choice to leave Earth permanently?
Current across a wire with zero potential difference
How do you funnel food off a cutting board?
Is a new boolean field better than null reference when a value can be meaningfully absent?
Premature ending of generator in list comprehension
Removing whitespace between consecutive numbers
I have trouble understanding this fallacy: "If A, then B. Therefore if not-B, then not-A."
Count repetitions of an array
Square Root Distance from Integers
Does diversity provide anything that meritocracy does not?
What is a DAG (Graph Theory)?
How do I append a character to the end of every line in an excel cell?
What will happen if Parliament votes "no" on each of the Brexit-related votes to be held on the 12th, 13th and 14th of March?
A Missing Symbol for This Logo
Why does photorec keep finding files after I have filled the disk free space as root?
Retrieve data from free space on 600Go disk after this disk have been dd of=/dev/{this disk} with 4Go data
Before I lend my laptop for a while to my young and linux-savy nephew I want to make sure he's not able to carve into my personal data in the blank space of the drive. I have saturated the blank space in the drive several times with
sudo cat /dev/urandom > some-file
Note the use of sudo, so that the 5% blank space reserved is ignored and the file grows until there is an error.
However, I execute photorec in that partition and then hundreds of old files pop out into existence. So, at least out of curiosity, where are those files stored and why does the random noise not overwrite them?
(The only explanation I have so far is, they might be in the empty space between the end of a file and the end of the sector that contains it. Could that be?)
data-recovery forensics
add a comment |
Before I lend my laptop for a while to my young and linux-savy nephew I want to make sure he's not able to carve into my personal data in the blank space of the drive. I have saturated the blank space in the drive several times with
sudo cat /dev/urandom > some-file
Note the use of sudo, so that the 5% blank space reserved is ignored and the file grows until there is an error.
However, I execute photorec in that partition and then hundreds of old files pop out into existence. So, at least out of curiosity, where are those files stored and why does the random noise not overwrite them?
(The only explanation I have so far is, they might be in the empty space between the end of a file and the end of the sector that contains it. Could that be?)
data-recovery forensics
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago
add a comment |
Before I lend my laptop for a while to my young and linux-savy nephew I want to make sure he's not able to carve into my personal data in the blank space of the drive. I have saturated the blank space in the drive several times with
sudo cat /dev/urandom > some-file
Note the use of sudo, so that the 5% blank space reserved is ignored and the file grows until there is an error.
However, I execute photorec in that partition and then hundreds of old files pop out into existence. So, at least out of curiosity, where are those files stored and why does the random noise not overwrite them?
(The only explanation I have so far is, they might be in the empty space between the end of a file and the end of the sector that contains it. Could that be?)
data-recovery forensics
Before I lend my laptop for a while to my young and linux-savy nephew I want to make sure he's not able to carve into my personal data in the blank space of the drive. I have saturated the blank space in the drive several times with
sudo cat /dev/urandom > some-file
Note the use of sudo, so that the 5% blank space reserved is ignored and the file grows until there is an error.
However, I execute photorec in that partition and then hundreds of old files pop out into existence. So, at least out of curiosity, where are those files stored and why does the random noise not overwrite them?
(The only explanation I have so far is, they might be in the empty space between the end of a file and the end of the sector that contains it. Could that be?)
data-recovery forensics
data-recovery forensics
edited 36 mins ago
Community♦
1
1
asked 8 hours ago
MephistoMephisto
304214
304214
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago
add a comment |
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago
add a comment |
3 Answers
3
active
oldest
votes
There may be several misunderstandings here, so the command does not do what you perhaps expect it to.
sudo
is superfluous since you don't need sudo
to read from /dev/urandom
. The > goddamnit
part is a shell redirection and thus not covered by sudo
at all. So your sudo
is super uneffective. (Note: in this particular case, sudo
might work as intended regardless, see comments. However, not using sudo
this way is a pattern as it bites you in other cases.)
Then, you're writing into a regular file. That does fill up free space - of the filesystem that file happens to reside on. If you have multiple filesystems (one for /
, one for /home
, boot and swap partitions, etc.) then those are also unaffected.
At best this only overwrites free space. There is no guarantee that it will cover everything (depends on filesystem internals, root reserve, journal, otherwise packed/reserved/etc. sectors), and it does not overwrite any file that is still there regularly (and those can include files hidden away in trashcan / thumbnail / cache folders or just some subdir you forgot about).
All of those will still be picked up by photorec
since it's never overwritten.
Furthermore, writing this file has to be completed first. So instead of deleting it directly afterwards, you'd have to sync
first to make sure all that random data actually hit the disk, and not just some RAM write buffer and never gets written.
So with this method, there is no guarantee for anything. At the same time it's dangerous, as the filesystem will run out of free space, which in turn can cause write failures for all other programs and thus result in unintentional data loss.
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on thewrite
call, and the exception is based on who calledwrite
.
– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to usesudo
this way, as it gives the wrong idea about howsudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)
– frostschutz
7 hours ago
add a comment |
Try using the sfill (Secure fill) tool in secure delete.
sudo apt-get install secure-delete
(from https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux )
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
add a comment |
How to get rid of all data, that your nephew should not see
I think there is only one way that is likely to overwrite all the locations, where 'deleted' data might remain.
Backup your system (a complete backup). One alternative is to make a cloned image with Clonezilla.
Wipe the whole drive (assuming one drive). If an HDD or SSD, there are special tools/methods, that work at a low level (change the mapping between logical and physical memory locations), and they are much faster than for example letting
dd
overwrite with zeros. You can often access such tools (built-in the drives) viahdparm
.Make a fresh installation and hand over the computer to the young and linux-savvy nephew.
The easy way
But if you can afford it, unplug your internal drive and replace it with a fresh drive. Let your nephew install his favourite linux distro :-)
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f503184%2fwhy-does-photorec-keep-finding-files-after-i-have-filled-the-disk-free-space-as%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
There may be several misunderstandings here, so the command does not do what you perhaps expect it to.
sudo
is superfluous since you don't need sudo
to read from /dev/urandom
. The > goddamnit
part is a shell redirection and thus not covered by sudo
at all. So your sudo
is super uneffective. (Note: in this particular case, sudo
might work as intended regardless, see comments. However, not using sudo
this way is a pattern as it bites you in other cases.)
Then, you're writing into a regular file. That does fill up free space - of the filesystem that file happens to reside on. If you have multiple filesystems (one for /
, one for /home
, boot and swap partitions, etc.) then those are also unaffected.
At best this only overwrites free space. There is no guarantee that it will cover everything (depends on filesystem internals, root reserve, journal, otherwise packed/reserved/etc. sectors), and it does not overwrite any file that is still there regularly (and those can include files hidden away in trashcan / thumbnail / cache folders or just some subdir you forgot about).
All of those will still be picked up by photorec
since it's never overwritten.
Furthermore, writing this file has to be completed first. So instead of deleting it directly afterwards, you'd have to sync
first to make sure all that random data actually hit the disk, and not just some RAM write buffer and never gets written.
So with this method, there is no guarantee for anything. At the same time it's dangerous, as the filesystem will run out of free space, which in turn can cause write failures for all other programs and thus result in unintentional data loss.
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on thewrite
call, and the exception is based on who calledwrite
.
– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to usesudo
this way, as it gives the wrong idea about howsudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)
– frostschutz
7 hours ago
add a comment |
There may be several misunderstandings here, so the command does not do what you perhaps expect it to.
sudo
is superfluous since you don't need sudo
to read from /dev/urandom
. The > goddamnit
part is a shell redirection and thus not covered by sudo
at all. So your sudo
is super uneffective. (Note: in this particular case, sudo
might work as intended regardless, see comments. However, not using sudo
this way is a pattern as it bites you in other cases.)
Then, you're writing into a regular file. That does fill up free space - of the filesystem that file happens to reside on. If you have multiple filesystems (one for /
, one for /home
, boot and swap partitions, etc.) then those are also unaffected.
At best this only overwrites free space. There is no guarantee that it will cover everything (depends on filesystem internals, root reserve, journal, otherwise packed/reserved/etc. sectors), and it does not overwrite any file that is still there regularly (and those can include files hidden away in trashcan / thumbnail / cache folders or just some subdir you forgot about).
All of those will still be picked up by photorec
since it's never overwritten.
Furthermore, writing this file has to be completed first. So instead of deleting it directly afterwards, you'd have to sync
first to make sure all that random data actually hit the disk, and not just some RAM write buffer and never gets written.
So with this method, there is no guarantee for anything. At the same time it's dangerous, as the filesystem will run out of free space, which in turn can cause write failures for all other programs and thus result in unintentional data loss.
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on thewrite
call, and the exception is based on who calledwrite
.
– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to usesudo
this way, as it gives the wrong idea about howsudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)
– frostschutz
7 hours ago
add a comment |
There may be several misunderstandings here, so the command does not do what you perhaps expect it to.
sudo
is superfluous since you don't need sudo
to read from /dev/urandom
. The > goddamnit
part is a shell redirection and thus not covered by sudo
at all. So your sudo
is super uneffective. (Note: in this particular case, sudo
might work as intended regardless, see comments. However, not using sudo
this way is a pattern as it bites you in other cases.)
Then, you're writing into a regular file. That does fill up free space - of the filesystem that file happens to reside on. If you have multiple filesystems (one for /
, one for /home
, boot and swap partitions, etc.) then those are also unaffected.
At best this only overwrites free space. There is no guarantee that it will cover everything (depends on filesystem internals, root reserve, journal, otherwise packed/reserved/etc. sectors), and it does not overwrite any file that is still there regularly (and those can include files hidden away in trashcan / thumbnail / cache folders or just some subdir you forgot about).
All of those will still be picked up by photorec
since it's never overwritten.
Furthermore, writing this file has to be completed first. So instead of deleting it directly afterwards, you'd have to sync
first to make sure all that random data actually hit the disk, and not just some RAM write buffer and never gets written.
So with this method, there is no guarantee for anything. At the same time it's dangerous, as the filesystem will run out of free space, which in turn can cause write failures for all other programs and thus result in unintentional data loss.
There may be several misunderstandings here, so the command does not do what you perhaps expect it to.
sudo
is superfluous since you don't need sudo
to read from /dev/urandom
. The > goddamnit
part is a shell redirection and thus not covered by sudo
at all. So your sudo
is super uneffective. (Note: in this particular case, sudo
might work as intended regardless, see comments. However, not using sudo
this way is a pattern as it bites you in other cases.)
Then, you're writing into a regular file. That does fill up free space - of the filesystem that file happens to reside on. If you have multiple filesystems (one for /
, one for /home
, boot and swap partitions, etc.) then those are also unaffected.
At best this only overwrites free space. There is no guarantee that it will cover everything (depends on filesystem internals, root reserve, journal, otherwise packed/reserved/etc. sectors), and it does not overwrite any file that is still there regularly (and those can include files hidden away in trashcan / thumbnail / cache folders or just some subdir you forgot about).
All of those will still be picked up by photorec
since it's never overwritten.
Furthermore, writing this file has to be completed first. So instead of deleting it directly afterwards, you'd have to sync
first to make sure all that random data actually hit the disk, and not just some RAM write buffer and never gets written.
So with this method, there is no guarantee for anything. At the same time it's dangerous, as the filesystem will run out of free space, which in turn can cause write failures for all other programs and thus result in unintentional data loss.
edited 7 hours ago
answered 8 hours ago
frostschutzfrostschutz
27.2k15584
27.2k15584
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on thewrite
call, and the exception is based on who calledwrite
.
– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to usesudo
this way, as it gives the wrong idea about howsudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)
– frostschutz
7 hours ago
add a comment |
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on thewrite
call, and the exception is based on who calledwrite
.
– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to usesudo
this way, as it gives the wrong idea about howsudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)
– frostschutz
7 hours ago
1
1
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
The sudo is there to ensure writing to the 5% (or some similar amount) reserved space, otherwise it will stop writing at the same time when the normal user file browsers report 0 bytes. With sudo, it does write an additional 50 GB more or less, don't ask me why.
– Mephisto
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
@Mephisto I admit I haven't tested it ( difficult for me since sudo is not installed here ) so I could be wrong about it, and shell redirection only is a problem when trying to write to a file already owned by root ( no permission to open / append as that's done by the shell before sudo runs ).
– frostschutz
8 hours ago
1
1
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on the
write
call, and the exception is based on who called write
.– Gilles
7 hours ago
I confirm, we were wrong about the reserved space not filling up: what matters is the EUID of the file doing the writing, not the ownership of the file. It makes sense in retrospect — the way the restriction works is that the kernel returns ENOSPC on the
write
call, and the exception is based on who called write
.– Gilles
7 hours ago
Thanks for confirming, I'd still argue it's bad style to use
sudo
this way, as it gives the wrong idea about how sudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)– frostschutz
7 hours ago
Thanks for confirming, I'd still argue it's bad style to use
sudo
this way, as it gives the wrong idea about how sudo
normally works when writing to files. (I'd also argue that writing random data is better than writing zero, you never know if the filesystem or storage device compresses/deduplicates data.)– frostschutz
7 hours ago
add a comment |
Try using the sfill (Secure fill) tool in secure delete.
sudo apt-get install secure-delete
(from https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux )
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
add a comment |
Try using the sfill (Secure fill) tool in secure delete.
sudo apt-get install secure-delete
(from https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux )
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
add a comment |
Try using the sfill (Secure fill) tool in secure delete.
sudo apt-get install secure-delete
(from https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux )
Try using the sfill (Secure fill) tool in secure delete.
sudo apt-get install secure-delete
(from https://superuser.com/questions/19326/how-to-wipe-free-disk-space-in-linux )
answered 8 hours ago
L. Scott JohnsonL. Scott Johnson
1905
1905
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
add a comment |
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
1
1
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
This does not answer the question, which asks “why”.
– Gilles
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
But that thing, acording to man sfill will do a lot of passes of zeros, noise and special values. This is overwriting the same area I overwrite with one (actually 4 by now) pass. Those files must be stored somewhere else.
– Mephisto
8 hours ago
1
1
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.
– L. Scott Johnson
8 hours ago
add a comment |
How to get rid of all data, that your nephew should not see
I think there is only one way that is likely to overwrite all the locations, where 'deleted' data might remain.
Backup your system (a complete backup). One alternative is to make a cloned image with Clonezilla.
Wipe the whole drive (assuming one drive). If an HDD or SSD, there are special tools/methods, that work at a low level (change the mapping between logical and physical memory locations), and they are much faster than for example letting
dd
overwrite with zeros. You can often access such tools (built-in the drives) viahdparm
.Make a fresh installation and hand over the computer to the young and linux-savvy nephew.
The easy way
But if you can afford it, unplug your internal drive and replace it with a fresh drive. Let your nephew install his favourite linux distro :-)
add a comment |
How to get rid of all data, that your nephew should not see
I think there is only one way that is likely to overwrite all the locations, where 'deleted' data might remain.
Backup your system (a complete backup). One alternative is to make a cloned image with Clonezilla.
Wipe the whole drive (assuming one drive). If an HDD or SSD, there are special tools/methods, that work at a low level (change the mapping between logical and physical memory locations), and they are much faster than for example letting
dd
overwrite with zeros. You can often access such tools (built-in the drives) viahdparm
.Make a fresh installation and hand over the computer to the young and linux-savvy nephew.
The easy way
But if you can afford it, unplug your internal drive and replace it with a fresh drive. Let your nephew install his favourite linux distro :-)
add a comment |
How to get rid of all data, that your nephew should not see
I think there is only one way that is likely to overwrite all the locations, where 'deleted' data might remain.
Backup your system (a complete backup). One alternative is to make a cloned image with Clonezilla.
Wipe the whole drive (assuming one drive). If an HDD or SSD, there are special tools/methods, that work at a low level (change the mapping between logical and physical memory locations), and they are much faster than for example letting
dd
overwrite with zeros. You can often access such tools (built-in the drives) viahdparm
.Make a fresh installation and hand over the computer to the young and linux-savvy nephew.
The easy way
But if you can afford it, unplug your internal drive and replace it with a fresh drive. Let your nephew install his favourite linux distro :-)
How to get rid of all data, that your nephew should not see
I think there is only one way that is likely to overwrite all the locations, where 'deleted' data might remain.
Backup your system (a complete backup). One alternative is to make a cloned image with Clonezilla.
Wipe the whole drive (assuming one drive). If an HDD or SSD, there are special tools/methods, that work at a low level (change the mapping between logical and physical memory locations), and they are much faster than for example letting
dd
overwrite with zeros. You can often access such tools (built-in the drives) viahdparm
.Make a fresh installation and hand over the computer to the young and linux-savvy nephew.
The easy way
But if you can afford it, unplug your internal drive and replace it with a fresh drive. Let your nephew install his favourite linux distro :-)
answered 7 hours ago
sudodussudodus
1,56837
1,56837
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f503184%2fwhy-does-photorec-keep-finding-files-after-i-have-filled-the-disk-free-space-as%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
@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)
– frostschutz
7 hours ago
Just wanted to focus on the core of the question...
– Jeff Schaller
7 hours ago
@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.
– Uncle Billy
7 hours ago
@Mephisto some filesystems store the content of small files and directories directly in the free space from the inode. Or at least so was my impression -- I'll have to check ;-)
– Uncle Billy
7 hours ago