| 8 Feb 2022 |
 atemu12 | tpw_rules: looks like the hardlink issue? Te PR that fixes it is still in staging I believe | 09:26:26 |
| atemu12 | * tpw_rules: looks like the hardlink issue? The PR that fixes it is still in staging I believe | 09:26:41 |
 raboof | hmm https://nixpk.gs/pr-tracker.html?pr=157235 suggests it should've made it by now | 09:41:59 |
 tpw_rules | the commit hash that page says it used has it | 18:35:03 |
| tpw_rules | as far as i can tell | 18:35:33 |
| tpw_rules | i was able to get a reproducible build for whatever hydra built on 4.15 with ext4 and 5.4 with zfs. i don't know what the column diffoscope is describing doesn't match is. inode number? | 23:27:28 |
| tpw_rules | (and on both systems pre and post store optimization) | 23:27:55 |
| tpw_rules | "nlink" apparently | 23:35:02 |
| atemu12 | So the patch didn't do anything? That's surprising. | 23:36:24 |
| tpw_rules | well it appears the formerly hardlinked files are not removed from the archive now? but the cpio directory entries are still different | 23:37:19 |
| tpw_rules | it works for me... | 23:37:21 |
| tpw_rules | also these are for directories anyway, and directories can't be hardlinked, right? | 23:40:12 |
| atemu12 | There's . and .. which are hardlinks but that should always be 2. | 23:46:58 |
| tpw_rules | i checked and my initrd has > 1 for nlink | 23:47:36 |
| atemu12 | >2? | 23:48:00 |
| tpw_rules | well it seems to match what the left column in the diff says | 23:48:15 |
| tpw_rules | dev is 2, etc is 3, and so on | 23:48:25 |
| atemu12 | What seems to match? | 23:49:43 |
| tpw_rules | the nlink values in the initrd hydra and i both built | 23:50:03 |
| tpw_rules | (which are the same) | 23:50:07 |
| atemu12 | But why is /etc 3? | 23:51:20 |
| tpw_rules | i don't know. that's what the file says | 23:51:34 |
| atemu12 | All directories should be 2 | 23:51:39 |
| tpw_rules | this says at least 2: https://www.systutorials.com/docs/linux/man/5-cpio/ | 23:51:56 |
| tpw_rules | which means that the file where they are all 1 seems invalid to me | 23:52:04 |
| atemu12 | macOS' HFS has directory hardlinks, so I'd assume support for >1 is for that | 23:52:42 |
| atemu12 | * macOS' HFS has directory hardlinks, so I'd assume support for >2 is for that | 23:53:26 |
| tpw_rules | i mean i hope this is not using HFS+ on linux | 23:53:38 |
| atemu12 | Don't think it supports dir hardlinks on Linux | 23:54:21 |
| atemu12 | Could you find out how nlink is determined? | 23:55:14 |
