Hard links? Relative path?

[Robert Simpson]

I'm building out a new APFS handler, and I'm having an issue trying to sort out hard links for extraction. Screenshots attached.
Basically if I extract the parent folder "bin", it reports an error for the hard link, which it's trying to resolve to the root folder of my extraction, and not the relative folder of "bin". I've tried it with the "./" prefix, I've tried without it (just the name), and have tried supplying a full path that matches the kpidPath of the original file, but nothing's working and all results in various "cannot find the file specified" errors and the error message points to a wrong location.

What should I be passing as the hard link name?

[Robert Simpson]

I'm kindof wondering if I'm supposed to be implementing one of the RawProps interfaces or something non-obvious ...

[Igor Pavlov]

There are two different ways to handle hard links in 7-Zip:
1) Hard link via string path kpidHardLink in Tar handler
2) Hard link via kpidINode / kpidStreamId in ntfs handler.

Look kpidINode strings in 7-zip source code.
Now I don't remember details about apfs code in 7-zip.
Probably it doesn't support hard links now. I don't remember why it's so.
Hardlink kpidINode feature must be enabled in GetArchiveProperty() like in ntfs code:

case kpidINode: prop = true; break;

Then the client willl try to use kpidINode values for hardlinks.

[Robert Simpson]

Thanks, I'll have a look at that. I've completely rewritten the apfs handler, using a severely stripped-down version of the apfs-fuse github project. I'm not sure if the apfs-fuse license and the 7z license are compatible.
Hard links are about the only thing left that aren't working atm. It's also got a bunch of duplicated code like crc32, aes, sha1/sha256 and a few other things that need to be merged in. I've replaced the zlib stuff with 7z's, but not the lzfn and lzfse code just yet.

[Robert Simpson]

Following the code in UI/Common/ArchiveExtractCallback, there's a very specific sequence it goes through to resolve a hard link, and it's not taking into account the current directory -- only the directory at the root of extraction. I could try passing in a formatted path like RAR does to force 7zFM through the RAR codepath, but even passing in kpidINode (true) in GetArchiveProperty doesn't get me anywhere. I can see there's a ReparsePoint/GetRawProps codepath for NTFS, but that's not where I'm getting or hitting.
CLinkInfo _link is saying isRelative is false, even with a relative path. kpidSymLink assumes relative, but kpidHardLink assumes absolute, but then only parses it if it's prefixed with \??\

[Robert Simpson]

I got it working. The hard link's path is a full path to the hard link, unlike a symlink with a relative path. One of the tricky issues was that sometimes the copy of the hardlink appears in a directory at a higher level than the original file, so it could appear first in searches, sorts, and so on.
So, I had to change the code to move symlinks and hard links to the bottom of my indexed list of files so they always (numerically) appear last. During iteration 7-zip will start at index 0 and work its way down, and by the time it gets to symlinks and hardlinks, it will have already created the references.