> Oops you're right... so we indeed need to handle this conflicting APIs,
> but fgetxattr_follow() is inapropriate, because fgetxattr() has nothing
> to follow since it already has an fd... The same goes with Darwin's
> version actually. The "nofollow" thingy only makes sense for those calls
> that
On Thu, 31 May 2018 12:14:30 -0400
Keno Fischer wrote:
> > I'm ok with this move, but if the functions need to have distinct
> > implementations, and they really do according to patch 10, then
> > I'd rather have distinct files and rely on conditional building in
> > the makefile. Maybe rename th
> I'm ok with this move, but if the functions need to have distinct
> implementations, and they really do according to patch 10, then
> I'd rather have distinct files and rely on conditional building in
> the makefile. Maybe rename the current file to 9p-util-linux.c
> and introduce a 9p-util-darwi
On Sat, 26 May 2018 01:23:05 -0400
k...@juliacomputing.com wrote:
> From: Keno Fischer
>
> These functions will need custom implementations on Darwin. Since the
> implementation is very similar among all of them, and 9p-util already
> has the _nofollow version of fgetxattrat, let's move them all
From: Keno Fischer
These functions will need custom implementations on Darwin. Since the
implementation is very similar among all of them, and 9p-util already
has the _nofollow version of fgetxattrat, let's move them all there.
Additionally, introduce a _follow version of fgetxattr and use it.
O
