[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-u

From: Keno Fischer
Subject: Re: [Qemu-devel] [PATCH 03/13] 9p: Move a couple xattr functions to 9p-util
Date: Thu, 31 May 2018 13:39:38 -0400

> 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 have a dirfd and pathname argument.
> The OSX manpage for fgetxattr() seem to mention the XATTR_NOFOLLOW flag
> for getxattr() only.
> https://www.unix.com/man-page/osx/2/fgetxattr/
> XATTR_NOFOLLOW  do not follow symbolic links.  getxattr() normally returns
>                 information from the target of path if it is a symbolic link.
>                 With this option, getxattr() will return extended attribute
>                 data from the symbolic link instead.

Ah sorry, you're correct of course. Will fix.

>> so I believe it needs to be factored out nevertheless. Are you just
>> proposing doing that later in the patch series?
> Maybe introduce a qemu_fgetxattr() API in 9p-utils.h ? In a separate patch, or
> maybe in patch 10.
> #define qemu_fgetxattr(...) fgetxattr(__VA_ARGS__, 0, 0)
> #else
> #define qemu_fgetxattr fgetxattr
> #endif

Sounds good. I'll do this in a separate patch, since the *at versions
are all similar while
this is a bit different.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]