How to create a hard link to an inode (ext4)?












11















If I know the index node (inode) of a file, but I don't know its path (or any of its paths), is it possible to create a hard link to that inode directly?



I could find the file using sudo find / -inum 123546 and then create a hardlink, but that would be way too slow for my application.



N.B. I'm using an ext4 filesystem.






inode hard-link







share|improve this question









New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

    – Gilles
    13 hours ago
















11















If I know the index node (inode) of a file, but I don't know its path (or any of its paths), is it possible to create a hard link to that inode directly?



I could find the file using sudo find / -inum 123546 and then create a hardlink, but that would be way too slow for my application.



N.B. I'm using an ext4 filesystem.






inode hard-link







share|improve this question









New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

    – Gilles
    13 hours ago














11












11








11


1






If I know the index node (inode) of a file, but I don't know its path (or any of its paths), is it possible to create a hard link to that inode directly?



I could find the file using sudo find / -inum 123546 and then create a hardlink, but that would be way too slow for my application.



N.B. I'm using an ext4 filesystem.






inode hard-link







share|improve this question









New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












If I know the index node (inode) of a file, but I don't know its path (or any of its paths), is it possible to create a hard link to that inode directly?



I could find the file using sudo find / -inum 123546 and then create a hardlink, but that would be way too slow for my application.



N.B. I'm using an ext4 filesystem.






inode hard-link




inode hard-link






share|improve this question









New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 11 hours ago









terdon♦

132k32261441




132k32261441






New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 14 hours ago









AstoneAstone

563




563




New contributor




Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Astone is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

    – Gilles
    13 hours ago



















  • Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

    – Gilles
    13 hours ago

















Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

– Gilles
13 hours ago





Closely related: removing or renaming a file via its inode (both of which are equally impossible to do directly).

– Gilles
13 hours ago










2 Answers
2






active

oldest

votes


















15














AFAIK, not with the kernel API. If such an interface existed, it would have to be limited to the super-user as otherwise that would let anyone access files in directories they don't have search access to.



But you could use debugfs on the file system (once it's unmounted) to do it (assuming you have write access to the block device).





debugfs -w /dev/block/device


(replace /dev/block/device with the actual block device the file system resides in).



Then, at the prompt of debugfs, enter




stat <123>
(with the angle brackets, replacing 123 with the actual inode number) to check that the file exists (inode has a link count greater than 0) and is not a directory.

If all good, enter:




ln <123> path/to/newfile
to create the hardlink (note that the path is relative to the root of the file system). Followed by:


mi <123>
to increment the link count (press Enter for all the fields except the link count where you'll want to add 1 to the current value).




share|improve this answer





















  • 4





    Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

    – Gilles
    13 hours ago






  • 1





    @Gilles related: unix.stackexchange.com/a/499760/308316

    – mosvy
    13 hours ago






  • 1





    @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

    – Stéphane Chazelas
    12 hours ago











  • @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

    – Philip Couling
    12 hours ago








  • 2





    @OrangeDog, search permission is the terminology used by the POSIX standard.

    – Stéphane Chazelas
    9 hours ago



















1














Depending on your use case, another approach could be to first collect all file candidates in one directory by hard linking it and then hard linking the files you are particularly interested in.



Such as 



mkdir -pm 0700 by-inode/{0..999}

find <path> ! -type d -printf "%i/%p" |

  while IFS=/ read -rd '' i n; do

    ln "$n" "by-inode/$((i/1000))/$i"

  done


(assuming your inode numbers are all less than 1,000,000, create more directories if need be).



Afterwards, your inodes are grouped 1000-wise and collected in the by-inode/ tree. From there, you can link them as needed.



Note though that it means that deleting files under <path> will not reclaim the space because of that extra hard link.






share|improve this answer

























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


    }
    });






    Astone is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f505815%2fhow-to-create-a-hard-link-to-an-inode-ext4%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    15














    AFAIK, not with the kernel API. If such an interface existed, it would have to be limited to the super-user as otherwise that would let anyone access files in directories they don't have search access to.



    But you could use debugfs on the file system (once it's unmounted) to do it (assuming you have write access to the block device).




    
debugfs -w /dev/block/device


    (replace /dev/block/device with the actual block device the file system resides in).



    Then, at the prompt of debugfs, enter




    stat <123>
    (with the angle brackets, replacing 123 with the actual inode number) to check that the file exists (inode has a link count greater than 0) and is not a directory.

    If all good, enter:




    ln <123> path/to/newfile
    to create the hardlink (note that the path is relative to the root of the file system). Followed by:


    mi <123>
    to increment the link count (press Enter for all the fields except the link count where you'll want to add 1 to the current value).




    share|improve this answer





















    • 4





      Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

      – Gilles
      13 hours ago






    • 1





      @Gilles related: unix.stackexchange.com/a/499760/308316

      – mosvy
      13 hours ago






    • 1





      @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

      – Stéphane Chazelas
      12 hours ago











    • @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

      – Philip Couling
      12 hours ago








    • 2





      @OrangeDog, search permission is the terminology used by the POSIX standard.

      – Stéphane Chazelas
      9 hours ago
















    15














    AFAIK, not with the kernel API. If such an interface existed, it would have to be limited to the super-user as otherwise that would let anyone access files in directories they don't have search access to.



    But you could use debugfs on the file system (once it's unmounted) to do it (assuming you have write access to the block device).




    
debugfs -w /dev/block/device


    (replace /dev/block/device with the actual block device the file system resides in).



    Then, at the prompt of debugfs, enter




    stat <123>
    (with the angle brackets, replacing 123 with the actual inode number) to check that the file exists (inode has a link count greater than 0) and is not a directory.

    If all good, enter:




    ln <123> path/to/newfile
    to create the hardlink (note that the path is relative to the root of the file system). Followed by:


    mi <123>
    to increment the link count (press Enter for all the fields except the link count where you'll want to add 1 to the current value).




    share|improve this answer





















    • 4





      Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

      – Gilles
      13 hours ago






    • 1





      @Gilles related: unix.stackexchange.com/a/499760/308316

      – mosvy
      13 hours ago






    • 1





      @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

      – Stéphane Chazelas
      12 hours ago











    • @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

      – Philip Couling
      12 hours ago








    • 2





      @OrangeDog, search permission is the terminology used by the POSIX standard.

      – Stéphane Chazelas
      9 hours ago














    15












    15








    15







    AFAIK, not with the kernel API. If such an interface existed, it would have to be limited to the super-user as otherwise that would let anyone access files in directories they don't have search access to.



    But you could use debugfs on the file system (once it's unmounted) to do it (assuming you have write access to the block device).




    
debugfs -w /dev/block/device


    (replace /dev/block/device with the actual block device the file system resides in).



    Then, at the prompt of debugfs, enter




    stat <123>
    (with the angle brackets, replacing 123 with the actual inode number) to check that the file exists (inode has a link count greater than 0) and is not a directory.

    If all good, enter:




    ln <123> path/to/newfile
    to create the hardlink (note that the path is relative to the root of the file system). Followed by:


    mi <123>
    to increment the link count (press Enter for all the fields except the link count where you'll want to add 1 to the current value).




    share|improve this answer















    AFAIK, not with the kernel API. If such an interface existed, it would have to be limited to the super-user as otherwise that would let anyone access files in directories they don't have search access to.



    But you could use debugfs on the file system (once it's unmounted) to do it (assuming you have write access to the block device).




    
debugfs -w /dev/block/device


    (replace /dev/block/device with the actual block device the file system resides in).



    Then, at the prompt of debugfs, enter




    stat <123>
    (with the angle brackets, replacing 123 with the actual inode number) to check that the file exists (inode has a link count greater than 0) and is not a directory.

    If all good, enter:




    ln <123> path/to/newfile
    to create the hardlink (note that the path is relative to the root of the file system). Followed by:


    mi <123>
    to increment the link count (press Enter for all the fields except the link count where you'll want to add 1 to the current value).





    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 11 hours ago

























    answered 13 hours ago









    Stéphane ChazelasStéphane Chazelas

    309k57582945




    309k57582945








    • 4





      Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

      – Gilles
      13 hours ago






    • 1





      @Gilles related: unix.stackexchange.com/a/499760/308316

      – mosvy
      13 hours ago






    • 1





      @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

      – Stéphane Chazelas
      12 hours ago











    • @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

      – Philip Couling
      12 hours ago








    • 2





      @OrangeDog, search permission is the terminology used by the POSIX standard.

      – Stéphane Chazelas
      9 hours ago














    • 4





      Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

      – Gilles
      13 hours ago






    • 1





      @Gilles related: unix.stackexchange.com/a/499760/308316

      – mosvy
      13 hours ago






    • 1





      @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

      – Stéphane Chazelas
      12 hours ago











    • @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

      – Philip Couling
      12 hours ago








    • 2





      @OrangeDog, search permission is the terminology used by the POSIX standard.

      – Stéphane Chazelas
      9 hours ago








    4




    4





    Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

    – Gilles
    13 hours ago





    Such an interface would also have to check that the file has a nonzero link count, otherwise it would be possible to resurrect a deleted-but-still-open file, which IIRC was rejected because it violates kernel invariants.

    – Gilles
    13 hours ago




    1




    1





    @Gilles related: unix.stackexchange.com/a/499760/308316

    – mosvy
    13 hours ago





    @Gilles related: unix.stackexchange.com/a/499760/308316

    – mosvy
    13 hours ago




    1




    1





    @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

    – Stéphane Chazelas
    12 hours ago





    @PhilipCouling, the execute permission bit on a directory translates to search permission. I already said in directories then don't have search access to.

    – Stéphane Chazelas
    12 hours ago













    @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

    – Philip Couling
    12 hours ago







    @StéphaneChazelas Yes I realise that. Though "search access" isn't self explanatory and the nomenclature is a touch misleading. For the sake of future readers, I think it's worth noting that that [search access / execute bit] infers restricted access to the children. This would help less experienced readers. It gives the logic in a single pass rather than forcing further google searches.

    – Philip Couling
    12 hours ago






    2




    2





    @OrangeDog, search permission is the terminology used by the POSIX standard.

    – Stéphane Chazelas
    9 hours ago





    @OrangeDog, search permission is the terminology used by the POSIX standard.

    – Stéphane Chazelas
    9 hours ago













    1














    Depending on your use case, another approach could be to first collect all file candidates in one directory by hard linking it and then hard linking the files you are particularly interested in.



    Such as 



    mkdir -pm 0700 by-inode/{0..999}
    
find <path> ! -type d -printf "%i/%p" |
    
  while IFS=/ read -rd '' i n; do
    
    ln "$n" "by-inode/$((i/1000))/$i"
    
  done


    (assuming your inode numbers are all less than 1,000,000, create more directories if need be).



    Afterwards, your inodes are grouped 1000-wise and collected in the by-inode/ tree. From there, you can link them as needed.



    Note though that it means that deleting files under <path> will not reclaim the space because of that extra hard link.






    share|improve this answer






























      1














      Depending on your use case, another approach could be to first collect all file candidates in one directory by hard linking it and then hard linking the files you are particularly interested in.



      Such as 



      mkdir -pm 0700 by-inode/{0..999}
      
find <path> ! -type d -printf "%i/%p" |
      
  while IFS=/ read -rd '' i n; do
      
    ln "$n" "by-inode/$((i/1000))/$i"
      
  done


      (assuming your inode numbers are all less than 1,000,000, create more directories if need be).



      Afterwards, your inodes are grouped 1000-wise and collected in the by-inode/ tree. From there, you can link them as needed.



      Note though that it means that deleting files under <path> will not reclaim the space because of that extra hard link.






      share|improve this answer




























        1












        1








        1







        Depending on your use case, another approach could be to first collect all file candidates in one directory by hard linking it and then hard linking the files you are particularly interested in.



        Such as 



        mkdir -pm 0700 by-inode/{0..999}
        
find <path> ! -type d -printf "%i/%p" |
        
  while IFS=/ read -rd '' i n; do
        
    ln "$n" "by-inode/$((i/1000))/$i"
        
  done


        (assuming your inode numbers are all less than 1,000,000, create more directories if need be).



        Afterwards, your inodes are grouped 1000-wise and collected in the by-inode/ tree. From there, you can link them as needed.



        Note though that it means that deleting files under <path> will not reclaim the space because of that extra hard link.






        share|improve this answer















        Depending on your use case, another approach could be to first collect all file candidates in one directory by hard linking it and then hard linking the files you are particularly interested in.



        Such as 



        mkdir -pm 0700 by-inode/{0..999}
        
find <path> ! -type d -printf "%i/%p" |
        
  while IFS=/ read -rd '' i n; do
        
    ln "$n" "by-inode/$((i/1000))/$i"
        
  done


        (assuming your inode numbers are all less than 1,000,000, create more directories if need be).



        Afterwards, your inodes are grouped 1000-wise and collected in the by-inode/ tree. From there, you can link them as needed.



        Note though that it means that deleting files under <path> will not reclaim the space because of that extra hard link.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 6 hours ago









        Toby Speight

        5,34811032




        5,34811032










        answered 8 hours ago









        glglglglglgl

        1,164812




        1,164812






















            Astone is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            Astone is a new contributor. Be nice, and check out our Code of Conduct.













            Astone is a new contributor. Be nice, and check out our Code of Conduct.












            Astone is a new contributor. Be nice, and check out our Code of Conduct.
















            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%2f505815%2fhow-to-create-a-hard-link-to-an-inode-ext4%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 to label and detect the document text images

            Image
            1 $begingroup$ This is what I mean as document text image: I want to label the texts in image as separate blocks and my model should detect these labels as classes. NOTE: This is how the end result should be like: The labels like Block 1, Block 2, Block 3,.. should be Logo, Title, Date,.. Others, etc. Work done: First approach : I tried to implement this method via Object Detection, it didn't work. It didn't even detect any text. Second approach : Then I tried it using PixelLink. As this model is build for scene text detection, it detected each and every text in the image. But this method can detect multiple lines of text if the threshold values are increased. But I have no idea how do I add labels to the text blocks. PIXEL_CLS_WEIGHT_all_ones = 'PIXEL_CLS_WEIGHT_all_ones' PIXEL_C...
            Read more

            Vallis Paradisi

            Image
            Coordinata: .mw-parser-output .geo-default,.mw-parser-output .geo-dms,.mw-parser-output .geo-dec{display:inline}.mw-parser-output .geo-nondefault,.mw-parser-output .geo-multi-punct{display:none}.mw-parser-output .longitude,.mw-parser-output .latitude{white-space:nowrap} 33°03′S 71°37′W  /  33.05°S 71.617°W  / -33.05; -71.617 Vallis Paradisi Res apud Vicidata repertae: Civitas : Chilia Numerus incolarum : 296 655 Zona horaria : UTC-4 Situs interretialis Nomen officiale : Valparaíso Gubernium Consilium : municipal council of Valparaíso Geographia Superficies : 401 600 000 Metrum quadratum Coniunctiones urbium Urbes gemellae : Ovetum , Badalona , Santa Fe , Ora longa , Sciamhaevum , Quantunia , Callao , Bat Yam , Melaka , Novorossiysk , Busan , Corduba , Odessa , Rosario , Malacca , Barcino , Soteropolis , Franciscopolis (California) , Guanajuato, Silao Tabula aut despectus Despectus in portum sinumque et urbem Vallis Paradisi Vallis Para...
            Read more

            Tabula Rosettana

            Image
            Tabula multilinguis Rosettana in Museo Britannico ostenditur. Tabula Rosettana, [1] etiam titulo OGIS 90 agnita, est stela decreto de rebus sacris in Aegypto anno 196 a.C.n. lato inscripta. Tabula iuxta Rosettam Aegypti, urbem in delta Nili et ad oram maris Mediterranei iacentem, anno 1799 a milite Francico reperta est. Inventio stelae, linguis duabus scripturisque tribus inscriptae, eruditis Instituti Aegypti statim nuntiata est; ibi enim iussu imperatoris Napoleonis eruditi omnium scientiarum (sub aegide Commissionis Scientiarum et Artium) properaverant cum expeditione Francica. Qua a Britannis mox debellata, tabula Rosettana Londinium missa hodie apud Museum Britannicum iacet. Textus Graecus cito lectus interpretationi textuum Aegyptiorum (in formis hieroglyphica et demotica expressorum) gradatim adiuvit. Denique textum plene interpretatus est Ioannes Franciscus Champollion. Ab opere eruditorum cumulativo coepit hodiernus scripturae hieroglyphicae linguaeque Aegyptiae a...
            Read more