From bcpierce at cis.upenn.edu Tue Dec 12 17:20:14 2017 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 12 Dec 2017 17:20:14 -0500 Subject: [Unison-hackers] High Sierra / resource forks Message-ID: <39C2F55F-D6FE-421B-B4FD-17E817F92487@cis.upenn.edu> 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: From bcpierce at cis.upenn.edu Tue Dec 26 20:25:24 2017 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 26 Dec 2017 20:25:24 -0500 Subject: [Unison-hackers] High Sierra / resource forks In-Reply-To: <39C2F55F-D6FE-421B-B4FD-17E817F92487@cis.upenn.edu> References: <39C2F55F-D6FE-421B-B4FD-17E817F92487@cis.upenn.edu> Message-ID: <5C14CFC8-CC75-4C84-B28B-A6B4877CBD94@cis.upenn.edu> 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 > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 74 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.ml Type: application/octet-stream Size: 587 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: