Why does photorec keep finding files after I have filled the disk free space as root?Retrieve data from free...

Ellipses aligned on the same boundary point

Has any human ever had the choice to leave Earth permanently?

Do "fields" always combine by addition?

False written accusations not made public - is there law to cover this?

How do I prevent a homebrew Grappling Hook feature from trivializing Tomb of Annihilation?

Does diversity provide anything that meritocracy does not?

Why don't key signatures indicate the tonic?

Why avoid shared user accounts?

What would you call a real market that is close to perfect competition?

Should I reinstall Linux when changing the laptop's CPU?

Issues resetting the ledger HWM

Square Root Distance from Integers

Boss asked me to sign a resignation paper without a date on it along with my new contract

Avoid page break between paragraphs

Question about integral of an odd function

How to visualize the Riemann-Roch theorem from complex analysis or geometric topology considerations?

What to look for when criticizing poetry?

"We can't save the customer" error after Migration - Magento 2.3

How to deal with possible delayed baggage?

Which communication protocol is used in AdLib sound card?

Early credit roll before the end of the film

How to not let the Identify spell spoil everything?

Non-Cancer terminal illness that can affect young (age 10-13) girls?

GRASS not working with QGIS 3.6



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













7















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?)










share|improve this question

























  • @JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

    – frostschutz
    17 hours ago











  • Just wanted to focus on the core of the question...

    – Jeff Schaller
    17 hours ago






  • 1





    @JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

    – Uncle Billy
    17 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
    17 hours ago


















7















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?)










share|improve this question

























  • @JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

    – frostschutz
    17 hours ago











  • Just wanted to focus on the core of the question...

    – Jeff Schaller
    17 hours ago






  • 1





    @JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

    – Uncle Billy
    17 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
    17 hours ago
















7












7








7


1






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?)










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 10 hours ago









Community

1




1










asked 18 hours ago









MephistoMephisto

319214




319214













  • @JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

    – frostschutz
    17 hours ago











  • Just wanted to focus on the core of the question...

    – Jeff Schaller
    17 hours ago






  • 1





    @JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

    – Uncle Billy
    17 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
    17 hours ago





















  • @JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

    – frostschutz
    17 hours ago











  • Just wanted to focus on the core of the question...

    – Jeff Schaller
    17 hours ago






  • 1





    @JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

    – Uncle Billy
    17 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
    17 hours ago



















@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

– frostschutz
17 hours ago





@JeffSchaller thanks, at least I'm not alone, makes me feel better ;-)

– frostschutz
17 hours ago













Just wanted to focus on the core of the question...

– Jeff Schaller
17 hours ago





Just wanted to focus on the core of the question...

– Jeff Schaller
17 hours ago




1




1





@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

– Uncle Billy
17 hours ago





@JeffSchaller it does not open the file as superuser, but it does write to it as superuser.

– Uncle Billy
17 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
17 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
17 hours ago












3 Answers
3






active

oldest

votes


















14














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 ineffective. (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 subdirectory 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.






share|improve this answer





















  • 2





    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
    18 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
    18 hours ago








  • 3





    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
    18 hours ago






  • 1





    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
    18 hours ago











  • It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

    – larsks
    29 mins ago



















8














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) via hdparm.


  • 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 :-)






share|improve this answer































    4














    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 )






    share|improve this answer



















    • 1





      This does not answer the question, which asks “why”.

      – Gilles
      18 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
      18 hours ago






    • 2





      Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

      – L. Scott Johnson
      18 hours ago











    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    14














    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 ineffective. (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 subdirectory 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.






    share|improve this answer





















    • 2





      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
      18 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
      18 hours ago








    • 3





      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
      18 hours ago






    • 1





      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
      18 hours ago











    • It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

      – larsks
      29 mins ago
















    14














    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 ineffective. (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 subdirectory 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.






    share|improve this answer





















    • 2





      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
      18 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
      18 hours ago








    • 3





      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
      18 hours ago






    • 1





      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
      18 hours ago











    • It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

      – larsks
      29 mins ago














    14












    14








    14







    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 ineffective. (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 subdirectory 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.






    share|improve this answer















    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 ineffective. (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 subdirectory 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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 1 hour ago









    Jeff Schaller

    42.5k1158135




    42.5k1158135










    answered 18 hours ago









    frostschutzfrostschutz

    27.3k15585




    27.3k15585








    • 2





      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
      18 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
      18 hours ago








    • 3





      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
      18 hours ago






    • 1





      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
      18 hours ago











    • It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

      – larsks
      29 mins ago














    • 2





      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
      18 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
      18 hours ago








    • 3





      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
      18 hours ago






    • 1





      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
      18 hours ago











    • It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

      – larsks
      29 mins ago








    2




    2





    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
    18 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
    18 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
    18 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
    18 hours ago






    3




    3





    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
    18 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
    18 hours ago




    1




    1





    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
    18 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
    18 hours ago













    It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

    – larsks
    29 mins ago





    It's not just bad style to use sudo this way; it is pointless. The redirection happens in the local shell before sudo executes. The file will be created as and written by the user id in effect before running sudo.

    – larsks
    29 mins ago













    8














    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) via hdparm.


    • 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 :-)






    share|improve this answer




























      8














      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) via hdparm.


      • 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 :-)






      share|improve this answer


























        8












        8








        8







        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) via hdparm.


        • 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 :-)






        share|improve this answer













        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) via hdparm.


        • 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 :-)







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 17 hours ago









        sudodussudodus

        1,62837




        1,62837























            4














            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 )






            share|improve this answer



















            • 1





              This does not answer the question, which asks “why”.

              – Gilles
              18 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
              18 hours ago






            • 2





              Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

              – L. Scott Johnson
              18 hours ago
















            4














            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 )






            share|improve this answer



















            • 1





              This does not answer the question, which asks “why”.

              – Gilles
              18 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
              18 hours ago






            • 2





              Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

              – L. Scott Johnson
              18 hours ago














            4












            4








            4







            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 )






            share|improve this answer













            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 )







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 18 hours ago









            L. Scott JohnsonL. Scott Johnson

            2005




            2005








            • 1





              This does not answer the question, which asks “why”.

              – Gilles
              18 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
              18 hours ago






            • 2





              Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

              – L. Scott Johnson
              18 hours ago














            • 1





              This does not answer the question, which asks “why”.

              – Gilles
              18 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
              18 hours ago






            • 2





              Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

              – L. Scott Johnson
              18 hours ago








            1




            1





            This does not answer the question, which asks “why”.

            – Gilles
            18 hours ago





            This does not answer the question, which asks “why”.

            – Gilles
            18 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
            18 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
            18 hours ago




            2




            2





            Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

            – L. Scott Johnson
            18 hours ago





            Well, I would say it's overwriting the area you intend to overwrite but are not quite successfully overwriting.

            – L. Scott Johnson
            18 hours ago


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Benedict Cumberbatch Contingut Inicis Debut professional Premis Filmografia bàsica Premis i...

            Monticle de plataforma Contingut Est de Nord Amèrica Interpretacions Altres cultures Vegeu...

            Escacs Janus Enllaços externs Menú de navegacióEscacs JanusJanusschachBrainKing.comChessV