Skip to contentSkip to conversation

xfsprogs/libhandle : How to get the handle for a symbolic link ?

DISCUSSION DENIEL Philippe 3 participants 4 messages Jun 1, 2010 – Jun 2, 2010

lore
Share & tools
lore
#0 lore raw

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).

Regards

Philippe

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw
Quoted 16 lines · DENIEL Philippe

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.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#2 lore raw

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

Quoted 20 lines · Dave Chinner
Quoted 17 lines · DENIEL Philippe

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).

Quoted 9 lines

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.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#3 lore raw
Quoted 4 lines · DENIEL Philippe

Hi Dave,

In fact, path_to_handle does not do the work correctly. Its code is this (extract from xfsprogs-3.0.3 sources) :

This is fixed as of xfsprogs 3.1.0. I would recommend to update to the latests xfsprogs (3.1.2) anyway.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs