xfsprogs/libhandle : How to get the handle for a symbolic link ?
DENIEL Philippe
philippe.deniel at CEA.FR
Wed Jun 2 02:20:31 CDT 2010
Hi Dave,
In fact, path_to_handle does not do the work correctly. Its code is this
(extract from xfsprogs-3.0.3 sources) :
int
path_to_handle(
char *path, /* input, path to convert */
void **hanp, /* output, pointer to data */
size_t *hlen) /* output, size of returned
data */
{
int fd;
int result;
comarg_t obj;
fd = open(path, O_RDONLY);
if (fd < 0)
return -1;
obj.path = path;
result = obj_to_handle(path, fd, XFS_IOC_PATH_TO_HANDLE,
obj, hanp, hlen);
close(fd);
return result;
}
As you see, it performs a open at the beginning, which will results in
opening the file pointed by the symlink or returns ENOENT if the path
"inside" the symlink does not exist. I tried using open with O_NOFOLLOW
option, but it changed nothing, I got ELOOP when opening the file (which
is a regular behavior so far).
Any other ideas ?
Philippe
Dave Chinner a écrit :
> On Tue, Jun 01, 2010 at 01:48:22PM +0200, DENIEL Philippe wrote:
>
>> Hi,
>>
>> I am currently developing a user space nfs server with various
>> backends. One of this backend module use xfsprogss's libhandle to
>> implement XFS support. I could do almost everything with
>> open_by_handle and fd_to_handle, used jointly with ATFILE_SOURCE
>> functions, but I do have a problem with symbolic links. To build an
>> xfs object's handle, I get its parent handle (now problem to this)
>> then I call "openat" to get the fd to the object before calling
>> fd_to_handle. This works ok, but not for symbolic link : the openat
>> with follow the link. I added the O_NOFOLLOW flag to openat, but now
>> openat return ELOOP instead.
>> I know there is a readlink_by_handle function in libhandle. How
>> could I build the related handle to be used as argument to it (I
>> mean, how to build a handle that refers to the symlink itself, not
>> the object it points to).
>>
>
> Doesn't path_to_handle() do what you want? From the man page:
>
> "... If the final component of the path name is a symbolic
> link, the handle returned is that of the link itself."
>
> Cheers,
>
> Dave.
>
More information about the xfs
mailing list