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

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}

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.

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

1

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

– Gilles
Mar 12 at 9:53

add a comment |

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.

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

1

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

– Gilles
Mar 12 at 9:53

add a comment |

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.

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

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

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

edited Mar 12 at 11:56

terdon♦

134k33270450

edited Mar 12 at 11:56

terdon♦

134k33270450

edited Mar 12 at 11:56

terdon♦

134k33270450

asked Mar 12 at 9:14

Astone

813

asked Mar 12 at 9:14

Astone

813

asked Mar 12 at 9:14

Astone

813

1

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

– Gilles
Mar 12 at 9:53

add a comment |

1

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

– Gilles
Mar 12 at 9:53

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

– Gilles
Mar 12 at 9:53

add a comment |

2 Answers
2

active

oldest

votes

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

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

5

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
Mar 12 at 9:53

2

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

– mosvy
Mar 12 at 10:16

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
Mar 12 at 11:03

3

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

– Stéphane Chazelas
Mar 12 at 14:28

1

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

|
show 2 more comments

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.

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

add a comment |

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

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

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

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

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

5

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
Mar 12 at 9:53

2

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

– mosvy
Mar 12 at 10:16

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
Mar 12 at 11:03

3

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

– Stéphane Chazelas
Mar 12 at 14:28

1

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

|
show 2 more comments

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

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

5

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
Mar 12 at 9:53

2

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

– mosvy
Mar 12 at 10:16

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
Mar 12 at 11:03

3

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

– Stéphane Chazelas
Mar 12 at 14:28

1

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

|
show 2 more comments

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

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

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

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

edited Mar 12 at 12:25

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

answered Mar 12 at 9:39

Stéphane Chazelas

314k57596954

5

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
Mar 12 at 9:53

2

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

– mosvy
Mar 12 at 10:16

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
Mar 12 at 11:03

3

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

– Stéphane Chazelas
Mar 12 at 14:28

1

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

|
show 2 more comments

5

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
Mar 12 at 9:53

2

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

– mosvy
Mar 12 at 10:16

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
Mar 12 at 11:03

3

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

– Stéphane Chazelas
Mar 12 at 14:28

1

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

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
Mar 12 at 9:53

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

– mosvy
Mar 12 at 10:16

@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
Mar 12 at 11:03

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

– Stéphane Chazelas
Mar 12 at 14:28

@mosvy: That check can be removed from kernel. You have to patch up a couple of places in VFS for it to not hose itself though. I did it while working on my thesis years ago.

– Joshua
Mar 12 at 15:19

|
show 2 more comments

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.

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

add a comment |

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.

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

add a comment |

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.

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

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.

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

edited Mar 12 at 16:47

Toby Speight

5,61811234

edited Mar 12 at 16:47

Toby Speight

5,61811234

edited Mar 12 at 16:47

Toby Speight

5,61811234

answered Mar 12 at 15:31

glglgl

1,174812

answered Mar 12 at 15:31

glglgl

1,174812

answered Mar 12 at 15:31

glglgl

1,174812

add a comment |

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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Jtdylktuy