<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><blockquote type="cite"><div dir="ltr">So don't worry Kristian, it is not you, it is Mac ;)</div></blockquote><div><br></div>I’m glad it’s not just me. Was thinking I was going insane for a minute there. I’m a bit puzzled as to what has changed though. It could possibly be that I upgraded to a newer MacOS version over Christmas. That usually means an upgrade to Xcode as well and that might have done… something. <div><br></div><div>Commenting on a few other things:</div><div><br></div><div><blockquote type="cite">To share the burden, I've just manually created a RC4 from a repackaged RC3 on the download server<br></blockquote><div><br></div>Thanks, Even. For the final release I’ll simply rename this file and upload it again. I believe that is the safest thing I can do this time around.</div><div><br></div><div><blockquote type="cite">`tar tzvf proj-data-1.17RC2.tar.gz` does work on Mac, but it ignores the ._ files, they are also not present after unpacking the archive.<br></blockquote><div><br></div>That explains why I couldn’t see the same files as you guys. I did run that exact command, as well as unpacking the files using two separate tools. Based on that I felt quite comfortable no bad files were in RC2 and RC3. Sneaky stuff.</div><div><br></div><div>Thanks for helping clear this up. I am not sure how to avoid this in the future. For now I think the best thing I can do is to delete my local copy of the PROJ-data repo and make a new clone. Hopefully that leaves me with a set of files without any extra MacOS attributes. That method doesn’t feel particularly foolproof though, so I think it is time to look into automating the release process. For another project I am working on, I have been looking into saving artifacts from GitHub Action runs and publishing them as releases on GitHub. I don’t think that would be too difficult to setup for PROJ-data.</div><div><br></div><div>/Kristian</div><div><div><br><blockquote type="cite"><div>On 28 Feb 2024, at 19.13, Javier Jimenez Shaw via PROJ <proj@lists.osgeo.org> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div><br></div><div><br></div><div>For the next time we should use a different prefix, now that we know that Mac is doing something special.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Feb 2024 at 19:04, Sebastiaan Couwenberg via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/28/24 6:28 PM, Kristian Evers via PROJ wrote:<br>
> I’m on a Mac and they don’t always behave as you would expect coming from a Linux system. For instance, Bas’ tar command doesn’t fly with my particular brand of tar:<br>
> <br>
> $ tar tavf proj-data-1.17RC2.tar.gz | grep '\._'<br>
> tar: Option -a is not permitted in mode -t<br>
<br>
-a is likely a GNU tar specific option. I'm remember cursing grep on <br>
Solaris not supporting -A/-B/-C back in the day.<br>
<br>
`tar tzvf proj-data-1.17RC2.tar.gz` does work on Mac, but it ignores the <br>
._ files, they are also not present after unpacking the archive.<br>
<br>
> Unpacking the file surprisingly doesn’t reveal anything either. You’d think this sort of thing was easy to figure out but here we are. I am not the release manager you deserve but the one you got. Sorry.<br>
<br>
Apparently the ._ files are an Mac thing for extended attributes:<br>
<br>
<br>
<a href="https://unix.stackexchange.com/questions/282055/a-lot-of-files-inside-a-tar" rel="noreferrer" target="_blank">https://unix.stackexchange.com/questions/282055/a-lot-of-files-inside-a-tar</a><br>
<br>
Kind Regards,<br>
<br>
Bas<br>
<br>
-- <br>
GPG Key ID: 4096R/6750F10AE88D4AF1<br>
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>
_______________________________________________<br>PROJ mailing list<br>PROJ@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/proj<br></div></blockquote></div><br></div></body></html>