Hardlink two sets of hardlinked fliles
Lets say I have n files, a_1 to a_b, all hardlinked to each other. Additionally, I have m files, b_1 to b_m, hardlinked to each other (but not to the a_* files).
What is the smartest way to point the b_* hardlinks to the a_* file? Iterate over b_1 and point each to a_1? Or is there a way to change the whole bunch together?
How would I find all b_* files, knowing one of the b files? I.e. how do I find all other files hardlinked to a given file? Preferably in Python, without scanning the complete filesystem?
links
add a comment |
Lets say I have n files, a_1 to a_b, all hardlinked to each other. Additionally, I have m files, b_1 to b_m, hardlinked to each other (but not to the a_* files).
What is the smartest way to point the b_* hardlinks to the a_* file? Iterate over b_1 and point each to a_1? Or is there a way to change the whole bunch together?
How would I find all b_* files, knowing one of the b files? I.e. how do I find all other files hardlinked to a given file? Preferably in Python, without scanning the complete filesystem?
links
add a comment |
Lets say I have n files, a_1 to a_b, all hardlinked to each other. Additionally, I have m files, b_1 to b_m, hardlinked to each other (but not to the a_* files).
What is the smartest way to point the b_* hardlinks to the a_* file? Iterate over b_1 and point each to a_1? Or is there a way to change the whole bunch together?
How would I find all b_* files, knowing one of the b files? I.e. how do I find all other files hardlinked to a given file? Preferably in Python, without scanning the complete filesystem?
links
Lets say I have n files, a_1 to a_b, all hardlinked to each other. Additionally, I have m files, b_1 to b_m, hardlinked to each other (but not to the a_* files).
What is the smartest way to point the b_* hardlinks to the a_* file? Iterate over b_1 and point each to a_1? Or is there a way to change the whole bunch together?
How would I find all b_* files, knowing one of the b files? I.e. how do I find all other files hardlinked to a given file? Preferably in Python, without scanning the complete filesystem?
links
links
asked 1 hour ago
BerndBernd
1313
1313
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
No these cannot be changed together. The reason is the constructs involved. For the sake of this discussion files come in three parts:
- File name(s)
- An inode
- File data
Where the pointers run file names --> inode --> file data. There is no reverse pointer to get from inode to file name.
The only way you can ever find the file names pointing to an inode is search the entire file system and check every file name (not recommended).
So yes you will need to change every hard link one by one.
One important note. While you can't find the hardlinks, you can know how many they are. It may be worth checking whether a_* or b_* has more hardlinks. That way you can choose the less linked file to destroy, and add more hardlinks the one that already has the most.
Remember that on ext3 there is a maximum of 65,000 hard links per file. I only mention this because I ran into this exact problem yesterday.
add a comment |
File names are one-way pointers to inodes. In the usual Unix filesystem structure, there's no direct way to get a pointer back.
This means that the only way to do what you want, is to find the b files, unlink them, and create new links to a in their place. You can't do it in one go.
Also, you can't find the hard links to a file directly, you have to scan the whole filesystem. The GNU and FreeBSD versions (at least) of find have the -inum and -samefile tests that can be used to find files (names) based on the inode.
With GNU find, you should be able to do something like this to find the files that are hard links to b (including b itself), and to replace them with links to a:
find -samefile b -exec sh -c 'ln -f a "$1"' sh {} ;
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501462%2fhardlink-two-sets-of-hardlinked-fliles%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
No these cannot be changed together. The reason is the constructs involved. For the sake of this discussion files come in three parts:
- File name(s)
- An inode
- File data
Where the pointers run file names --> inode --> file data. There is no reverse pointer to get from inode to file name.
The only way you can ever find the file names pointing to an inode is search the entire file system and check every file name (not recommended).
So yes you will need to change every hard link one by one.
One important note. While you can't find the hardlinks, you can know how many they are. It may be worth checking whether a_* or b_* has more hardlinks. That way you can choose the less linked file to destroy, and add more hardlinks the one that already has the most.
Remember that on ext3 there is a maximum of 65,000 hard links per file. I only mention this because I ran into this exact problem yesterday.
add a comment |
No these cannot be changed together. The reason is the constructs involved. For the sake of this discussion files come in three parts:
- File name(s)
- An inode
- File data
Where the pointers run file names --> inode --> file data. There is no reverse pointer to get from inode to file name.
The only way you can ever find the file names pointing to an inode is search the entire file system and check every file name (not recommended).
So yes you will need to change every hard link one by one.
One important note. While you can't find the hardlinks, you can know how many they are. It may be worth checking whether a_* or b_* has more hardlinks. That way you can choose the less linked file to destroy, and add more hardlinks the one that already has the most.
Remember that on ext3 there is a maximum of 65,000 hard links per file. I only mention this because I ran into this exact problem yesterday.
add a comment |
No these cannot be changed together. The reason is the constructs involved. For the sake of this discussion files come in three parts:
- File name(s)
- An inode
- File data
Where the pointers run file names --> inode --> file data. There is no reverse pointer to get from inode to file name.
The only way you can ever find the file names pointing to an inode is search the entire file system and check every file name (not recommended).
So yes you will need to change every hard link one by one.
One important note. While you can't find the hardlinks, you can know how many they are. It may be worth checking whether a_* or b_* has more hardlinks. That way you can choose the less linked file to destroy, and add more hardlinks the one that already has the most.
Remember that on ext3 there is a maximum of 65,000 hard links per file. I only mention this because I ran into this exact problem yesterday.
No these cannot be changed together. The reason is the constructs involved. For the sake of this discussion files come in three parts:
- File name(s)
- An inode
- File data
Where the pointers run file names --> inode --> file data. There is no reverse pointer to get from inode to file name.
The only way you can ever find the file names pointing to an inode is search the entire file system and check every file name (not recommended).
So yes you will need to change every hard link one by one.
One important note. While you can't find the hardlinks, you can know how many they are. It may be worth checking whether a_* or b_* has more hardlinks. That way you can choose the less linked file to destroy, and add more hardlinks the one that already has the most.
Remember that on ext3 there is a maximum of 65,000 hard links per file. I only mention this because I ran into this exact problem yesterday.
answered 1 hour ago
Philip CoulingPhilip Couling
1,066817
1,066817
add a comment |
add a comment |
File names are one-way pointers to inodes. In the usual Unix filesystem structure, there's no direct way to get a pointer back.
This means that the only way to do what you want, is to find the b files, unlink them, and create new links to a in their place. You can't do it in one go.
Also, you can't find the hard links to a file directly, you have to scan the whole filesystem. The GNU and FreeBSD versions (at least) of find have the -inum and -samefile tests that can be used to find files (names) based on the inode.
With GNU find, you should be able to do something like this to find the files that are hard links to b (including b itself), and to replace them with links to a:
find -samefile b -exec sh -c 'ln -f a "$1"' sh {} ;
add a comment |
File names are one-way pointers to inodes. In the usual Unix filesystem structure, there's no direct way to get a pointer back.
This means that the only way to do what you want, is to find the b files, unlink them, and create new links to a in their place. You can't do it in one go.
Also, you can't find the hard links to a file directly, you have to scan the whole filesystem. The GNU and FreeBSD versions (at least) of find have the -inum and -samefile tests that can be used to find files (names) based on the inode.
With GNU find, you should be able to do something like this to find the files that are hard links to b (including b itself), and to replace them with links to a:
find -samefile b -exec sh -c 'ln -f a "$1"' sh {} ;
add a comment |
File names are one-way pointers to inodes. In the usual Unix filesystem structure, there's no direct way to get a pointer back.
This means that the only way to do what you want, is to find the b files, unlink them, and create new links to a in their place. You can't do it in one go.
Also, you can't find the hard links to a file directly, you have to scan the whole filesystem. The GNU and FreeBSD versions (at least) of find have the -inum and -samefile tests that can be used to find files (names) based on the inode.
With GNU find, you should be able to do something like this to find the files that are hard links to b (including b itself), and to replace them with links to a:
find -samefile b -exec sh -c 'ln -f a "$1"' sh {} ;
File names are one-way pointers to inodes. In the usual Unix filesystem structure, there's no direct way to get a pointer back.
This means that the only way to do what you want, is to find the b files, unlink them, and create new links to a in their place. You can't do it in one go.
Also, you can't find the hard links to a file directly, you have to scan the whole filesystem. The GNU and FreeBSD versions (at least) of find have the -inum and -samefile tests that can be used to find files (names) based on the inode.
With GNU find, you should be able to do something like this to find the files that are hard links to b (including b itself), and to replace them with links to a:
find -samefile b -exec sh -c 'ln -f a "$1"' sh {} ;
edited 1 hour ago
answered 1 hour ago
ilkkachuilkkachu
59.1k892167
59.1k892167
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f501462%2fhardlink-two-sets-of-hardlinked-fliles%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown