Clone hardlinks #467
Merged
Clone hardlinks #467
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I haven't gone any further with this because it can't be done atomically so there is some risk that the hardlink gets deleted or renamed. I could do a bit more work to make it more robust but will wait to see if there is any more interest in #466 |
|
Ok managed to make it reasonably atomic by cloning to a tempfile in the target dir and then atomically renaming that over the top of the hardlink. |
# Conflicts: # lib/formats/json.c
Use json-glib instead of home-grown json encoding
Implement new options to fully hash unique files
# Conflicts: # lib/session.c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #466.
This PR enables hardlink-clones to be converted to reflink-clones via a single command
rmlint --dedupe <original> <hardlink>, while preserving file permissions and times.Note that converting hardlink to reflink doesn't free any space, in fact it consumes a little bit for the necessary metadata. The advantage is that it de-links the two files' metadata, so that subsequent changes to permissions, access times etc are independent for the two files. Also modifications such as appending data to the original won't affect the reflink the way it would the hardlink.
Note that this implementation does temporarily delete the hardlink, so an untimely crash or error could see the hardlink lost (but not the original file). The workaround would require generating a unique temporary file name for the reflink.
Happy to discuss.