[Unison-hackers] High Sierra / resource forks

[Benjamin C. Pierce]

Follow-up…

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.

Doing a bit more reading about the new APFS, I came across this:

In macOS, the resource fork is also considered to be metadata, and stored as an xattr.

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.  

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:

      Unix.out_channel_of_descr
        (Fs.openfile p [Unix.O_WRONLY;Unix.O_TRUNC] 0o600)

Anybody have any idea?

    - B




> On Dec 12, 2017, at 5:20 PM, Benjamin C. Pierce <bcpierce at cis.upenn.edu <mailto:bcpierce at cis.upenn.edu>> wrote:
> 
> We were warned a couple months ago that at least one person was having trouble with strange transfer failures on OSX 10.13 (High Sierra).  I did some digging today and was able to track it down to a fingerprint mismatch on the transferred resource fork (which looked like a failure in the “rename” operation, because of some silliness).  Specifically, it appears that the received file has an empty resource fork, although the original had a non-empty one.  That’s as far as I got, and I need to switch to other things now, but I wonder...
> Does anybody know anything about recent changes in the way resource forks work in OSX?
> Has anybody else who has had their hands in this part of the code upgraded to High Sierra yet?
> Thanks!
> 
>    - Benjamin
> 
> P.S.  I created a HighSierraDebugging branch to play with.  Most of the changes are extra debugging statements, but I also masked the wrong failure message.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20171226/2e874500/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 74 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20171226/2e874500/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20171226/2e874500/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ml
Type: application/octet-stream
Size: 587 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20171226/2e874500/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20171226/2e874500/attachment-0002.html>