feat: handle hardlinks #17
Conversation
zhijie-yang
force-pushed
the
ROCKS-1249-handle-hardlinks
branch
from
e1abecc
to
0601fda
Compare
This reverts commit 19fc4ff.
The implementation of |
There was a problem hiding this comment.
Thanks for the changes James. I think we are only need one more round to get this approved :D. Most of the comments are about changing the code to match the style of Chisel a bit more, which is always the tedious part in the beginning until we both share the same mindset.
There was a problem hiding this comment.
Hey James, another quick review pending the last pass. I see that you removed the changes to treedump.go that would print whether an entry is a hardlink. I think we should keep the changes in treedump.go even though we don't use it right now. I think that it is useful when:
- we need to write other tests using it in the future,
- debugging, think about a test that creates a hardlink when it shouldn't. If we do not introduce the changes then the output is going to be identical to a regular file and we won't be able to differentiate it.
internal/fsutil/create.go
Outdated
| if os.SameFile(targetInfo, linkInfo) { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
I did some more tests and ln does not respect this, let's remove it. Probably previous comment about naming does not apply as we no longer need those variables.
There was a problem hiding this comment.
Bookkeeping: As per the offline discussion, this has to exist since there can be different slices in one package that create the same hard link multiple times.
This PR enables chisel to handle hard links. This is based on the assumption that the hard link and the target file are within the same tarball. If the hard links are not in the same slice as the target files in the slice definition file, the slice containing the target files should be included as the
essentialof the slice that contains the hard links.Related Discussion:
canonical/chisel-releases#259 (comment)