Invalid file links in 1.4 release candidate #2046
Comments
|
Thanks for this report! I will try and look into this and fix it before the next RC... Do you get this for all three of the file formats (gz, bz2, xz)? Do you get the same thing for the tarball provided by GitHub? |
|
I went back and checked all of the links:
Its not clear to me what makes the assets different from the release but those three all have the same problem with static archives. |
|
Number 1 is a tarball generated by GitHub itself, numbers 2-4 we generate ourselves by running "make dist" and upload to the release manually. So it at least makes sense that all the broken ones came from the same source... also since you had the same problem with each I'm fairly certain the issue is with the underlying tar format and not the compression applied on top of it. I have definitely seen problems in the past with tarballs generated by running "make dist" on OSX, so we always generate them on a Linux box now. I haven't seen a case where a Mac has trouble opening a tarball created under Linux. I also don't have a Mac handy at the moment for testing (and all of these untar for me just fine under Ubuntu) so I might need your help in tracking down the problem... |
|
I can only reproduce this issue on my workstation; its likely due to something strange AFS is doing. |
|
OK, well it's good there is the one working tarball from GitHub I guess... if I come across anything relevant I'll try and post on this issue. If anyone else out there on a Mac using AFS or not (maybe @milljm has a second to try this) wants to try unpacking one of these tarballs, that would also be awesome! |
|
I think we may be talking about two different things: the AFS I am using is the distributed Linux file system, not the new Mac one. |
|
Ha, indeed we were... the apple one is APFS. |
|
The files listed as having errors, extracts okay for me on Mojave with APSF. John knows I have plenty of systems at my disposal. I wouldn't mind doing some testing. |
|
Thanks @milljm! If we are to believe this old forum post, it's possible that "The AFS filesystem doesn't do hard links between directories." That would explain why the tarball from GitHub works on your system, as it contains only symbolic links (which AFS does support) while the "make dist" tarballs turn all those symbolic links into hard links for some reason. I'm not sure whether it's possible to control this behavior within the automake build system. |
|
Yup, thats definitely it: all the missing archives are hard-linked across directories. |
|
FYI, I believe I've tracked this issue down to the command that "make dist" runs to create the tarballs, i.e. In particular, the I don't know exactly what they mean by "dump" but apparently it results in making a hard link in the tar archive. I can kind of see why they would use this option by default, so that you wouldn't accidentally make a tarball with a broken/dangling symbolic link to something outside the main repo, but I don't think we really need it for libmesh. If it's possible to control the tar options used by autoconf, I'd definitely consider removing the |
Instead of setting TAR_OPTIONS, I also tried calling AC_SUBST(am__tar,[tar --hard-dereference]) but unforunately this alternate approach did not work, perhaps the AC_SUBST comes too late in the process to take effect or perhaps it is simply not possible to do this. It was an off-hand remark in a mailing list [0], not an officially sanctioned way of doing things. [0]: http://gnu-automake.7480.n7.nabble.com/bug-19616-dist-tarball-contains-hardlinks-td21667.html Refs libMesh#2046. Refs libMesh#2029.
Instead of setting TAR_OPTIONS, I also tried calling AC_SUBST(am__tar,[tar --hard-dereference]) but unforunately this alternate approach did not work, perhaps the AC_SUBST comes too late in the process to take effect or perhaps it is simply not possible to do this. It was an off-hand remark in a mailing list [0], not an officially sanctioned way of doing things. [0]: http://gnu-automake.7480.n7.nabble.com/bug-19616-dist-tarball-contains-hardlinks-td21667.html Refs #2046. Refs #2029.
|
@drwells would you mind giving the RC2 release tarballs a try? They should not contain any hard links, so hopefully they will work on AFS now. Thanks. |
|
It works: thanks a lot! |
|
OK, good to know. The tarballs got about 10% bigger due to this change, but I think the extra portability is worth it. |
I downloaded a copy of the 1.4 release candidate earlier and noticed some odd errors:
This only occurs for some of the
tecio.aarchives: I see tar errors for (Darwin) 10.8.0, 12.2.0, 11.4.2, 12.2.1, 10.7.0, and 12.5.0 and x86_64-pc-linux-gnu. I believe the rest are fine (i.e., I found 16 archives but expected 23).For the record: I am using AFS.
The text was updated successfully, but these errors were encountered: