"Roger A. Faulkner" <Roger.Faulkner at sun.com> wrote:

> I'm in agreement with the sentiment expressed here,
> and in fact I made the changes to support the pathconf()
> name _PC_TIMESTAMP_RESOLUTION in all the local file systems.
> ufs returns 1000 and zfs returns 1.

This seems to be correct.

> However, there is a problem with nfs.
> There is no over-the-wire protocol in nfs that can query
> the timestamp resolution of a remote file system.
> nfs's pathconf() issues one query to get a big block
> of attributes from the server and all of these attributes
> are fixed.  There is no over-the-wire pathconf() call
> for new, individual _PC_* names.

This seems to be unfortunate. There should be a way to allow to enhance 
the nfs protocol to match newer POSIX versions.

How about introducing a new call that sends the related ascii string over 
the wire in case that the pathconf() call was not defined at the time the 
related nfs version has been defined?

> nfs V3 and V4 both pass nanosecond-resolution time values
> over the wire, and utimensat() and futimens() will set
> nanosecond resolution time stamps on remotely-mounted file
> systems if the remote filesystems are zfs on the server side

This allows you to send nanosecond resolution for timestamps but not to
find out whether a non-identical timestamp on a remote file differs
from the time stamps in a tar archive because it differs or because the
remore resolution is not sufficient.

> But you can't (at least I can't) get the remote file system's
> time stamp resolution by any means other than actually attempting
> a utimensat() on it and examining the result with stat().

> Can you live with pathconf(_PC_TIMESTAMP_RESOLUTION) returning -1
> (with errno == EINVAL) for nfs-mounted files?

This is the way that is documented in POSIX.


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Reply via email to