<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Follow-up…<div class=""><br class=""></div><div class="">I think I’ve tracked down the issue. It appears that, on High Sierra, opening a resource fork requires slightly different parameters than on earlier filesystems. E.g., the attached test program fails on my High Sierra system, while it succeeds on an older 10.12 system.</div><div class=""><br class=""></div><div class="">Doing a bit more reading about the new APFS, I came across this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">In macOS, the resource fork is also considered to be metadata, and stored as an xattr.</div></blockquote><div class=""><div><br class=""></div><div>Writing to ..namedfork/rsrc appears still to work (i.e., it may be stored as an xattr now, but it can still be accessed as if it were an old-style resource fork), but it seems there’s some small difference. </div><div><br class=""></div><div>My main question, though, is whether anything bad will happen (in particular, on older OSX systems) if we just change O_TRUNC to O_CREAT in the openRessOut function in osx.ml, as my test suggests:</div><div><br class=""></div><div><div> Unix.out_channel_of_descr</div><div> (Fs.openfile p [Unix.O_WRONLY;Unix.O_TRUNC] 0o600)</div><div class=""><br class=""></div></div><div>Anybody have any idea?</div><div><br class=""></div><div> - B</div><div><br class=""></div><div></div></div></div></div></body></html>