How to recover files truncated by `>`?












2















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?










share|improve this question

























  • 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


















2















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?










share|improve this question

























  • 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
















2












2








2








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















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












3 Answers
3






active

oldest

votes


















3














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.






share|improve this answer
























  • 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





    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





















2














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





  1. apt-get install sleuthkit



  2. stat truncated-file | grep Inode

    remember the inode number (call it INODE_NUMBER)


  3. backup the file, then delete it:
    cp -a truncated-file truncated-file.old
    rm truncated-file


    1. debugfs /dev/disk-device



    2. stats

      look for Blocks per group

      This is very likely 32768. (call it BLOCKS_PER_GROUP)


    3. imap to get the block
      imap <$INODE_NUMBER>

      remember the block number (call it BLOCK_NUMBER)




  4. use blkls to copy the blocks to a file
    blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file


  5. 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?






share|improve this answer

































    0














    Sorry friend, It's impossible...



    You can recover deleted files but you can't recover a file with deleted content..






    share|improve this answer



















    • 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











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


    }
    });














    draft saved

    draft discarded


















    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









    3














    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.






    share|improve this answer
























    • 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





      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


















    3














    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.






    share|improve this answer
























    • 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





      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
















    3












    3








    3







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jan 9 '14 at 17:41









    souravcsouravc

    27.3k1377106




    27.3k1377106













    • 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





      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





















    • 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





      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



















    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















    2














    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





    1. apt-get install sleuthkit



    2. stat truncated-file | grep Inode

      remember the inode number (call it INODE_NUMBER)


    3. backup the file, then delete it:
      cp -a truncated-file truncated-file.old
      rm truncated-file


      1. debugfs /dev/disk-device



      2. stats

        look for Blocks per group

        This is very likely 32768. (call it BLOCKS_PER_GROUP)


      3. imap to get the block
        imap <$INODE_NUMBER>

        remember the block number (call it BLOCK_NUMBER)




    4. use blkls to copy the blocks to a file
      blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file


    5. 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?






    share|improve this answer






























      2














      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





      1. apt-get install sleuthkit



      2. stat truncated-file | grep Inode

        remember the inode number (call it INODE_NUMBER)


      3. backup the file, then delete it:
        cp -a truncated-file truncated-file.old
        rm truncated-file


        1. debugfs /dev/disk-device



        2. stats

          look for Blocks per group

          This is very likely 32768. (call it BLOCKS_PER_GROUP)


        3. imap to get the block
          imap <$INODE_NUMBER>

          remember the block number (call it BLOCK_NUMBER)




      4. use blkls to copy the blocks to a file
        blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file


      5. 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?






      share|improve this answer




























        2












        2








        2







        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





        1. apt-get install sleuthkit



        2. stat truncated-file | grep Inode

          remember the inode number (call it INODE_NUMBER)


        3. backup the file, then delete it:
          cp -a truncated-file truncated-file.old
          rm truncated-file


          1. debugfs /dev/disk-device



          2. stats

            look for Blocks per group

            This is very likely 32768. (call it BLOCKS_PER_GROUP)


          3. imap to get the block
            imap <$INODE_NUMBER>

            remember the block number (call it BLOCK_NUMBER)




        4. use blkls to copy the blocks to a file
          blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file


        5. 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?






        share|improve this answer















        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





        1. apt-get install sleuthkit



        2. stat truncated-file | grep Inode

          remember the inode number (call it INODE_NUMBER)


        3. backup the file, then delete it:
          cp -a truncated-file truncated-file.old
          rm truncated-file


          1. debugfs /dev/disk-device



          2. stats

            look for Blocks per group

            This is very likely 32768. (call it BLOCKS_PER_GROUP)


          3. imap to get the block
            imap <$INODE_NUMBER>

            remember the block number (call it BLOCK_NUMBER)




        4. use blkls to copy the blocks to a file
          blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file


        5. 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?







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 10 hours ago

























        answered Jul 15 '15 at 17:44









        JamesThomasMoon1979JamesThomasMoon1979

        1567




        1567























            0














            Sorry friend, It's impossible...



            You can recover deleted files but you can't recover a file with deleted content..






            share|improve this answer



















            • 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
















            0














            Sorry friend, It's impossible...



            You can recover deleted files but you can't recover a file with deleted content..






            share|improve this answer



















            • 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














            0












            0








            0







            Sorry friend, It's impossible...



            You can recover deleted files but you can't recover a file with deleted content..






            share|improve this answer













            Sorry friend, It's impossible...



            You can recover deleted files but you can't recover a file with deleted content..







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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














            • 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


















            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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

            How did Captain America manage to do this?

            迪纳利

            南乌拉尔铁路局