From sacadmin Thu Aug 20 19:39:23 2009 Received: from sunraf.sfbay.sun.com (sunraf.SFBay.Sun.COM [10.6.180.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7L2dNB9021893; Thu, 20 Aug 2009 19:39:23 -0700 (PDT) Received: from sunraf.sfbay.sun.com (localhost [127.0.0.1]) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7L2cBOP138299; Thu, 20 Aug 2009 19:38:11 -0700 (PDT) Received: (from raf@localhost) by sunraf.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n7L2cA3Y138295; Thu, 20 Aug 2009 19:38:10 -0700 (PDT) Date: Thu, 20 Aug 2009 19:38:10 -0700 (PDT) From: "Roger A. Faulkner" Message-Id: <200908210238.n7L2cA3Y138295@sunraf.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: futimens, utimensat [PSARC/2009/453 Self Review] Status: RO Content-Length: 560 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: futimens, utimensat 1.2. Name of Document Author/Supplier: Author: Roger Faulkner 1.3 Date of This Document: 20 August, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: OS-NET 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Roger.Faulkner@sun.com Thu Aug 20 19:59:56 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7L2xuOd022639 for ; Thu, 20 Aug 2009 19:59:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7L2xsSe013085; Thu, 20 Aug 2009 19:59:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOP00C01HNU3200@brm-avmta-1.central.sun.com>; Thu, 20 Aug 2009 20:59:54 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOP00MYJHNT5OE0@brm-avmta-1.central.sun.com>; Thu, 20 Aug 2009 20:59:53 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7L2xrvO341539; Thu, 20 Aug 2009 19:59:53 -0700 (PDT) Date: Thu, 20 Aug 2009 19:59:53 -0700 (PDT) From: "Roger A. Faulkner" Subject: PSARC/2009/453 - futimens, utimensat To: psarc-ext@sun.com Cc: Pavel.Filipensky@sun.com, bart.smaalders@sun.com, krister.johansen@sun.com, darrin.johnson@sun.com Reply-to: "Roger A. Faulkner" Message-id: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_116 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: zCSueijpGV4qlYe6FhV24w== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2224 I am sponsoring this automatic case for myself. 1. Introduction This case adds two new functions to the C library, futimens() and utimensat(), as follows: #include int futimens(int fd, const struct timespec times[2]); int utimensat(int fd, const char *path, const struct timespec times[2], int flag); The commitment level of these interfaces is Committed. The release binding is "patch" (so it can be back-ported to Solaris 10 if required). 2. Discussion Problems with, for example, make on ZFS file systems have emerged because ZFS keeps access and modification times for its files with nanosecond granularity, while commands such as touch(1) will only set access and modification times of its target files to microsecond granularity (rounded down). See the bugid: 6539657 touch(1) does not set the nanosecond timestamp of a file correctly The touch(1) command (and possibly others) need a system call interface that sets access and modification times of files with nanosecond granularity. Happily, such interfaces have been designed and are specified in the latest SUSv4 Posix interface specification: #include int futimens(int fd, const struct timespec times[2]); int utimensat(int fd, const char *path, const struct timespec times[2], int flag); Even though Solaris does not (yet) implement the new Posix standard, there is nothing stopping Solaris from providing a few of the newly-specified interfaces (provided that the names are appropriately hidden from view when an old standards-conforming application is compiled). 3. Interface table Both functions are Committed. Both are specified by the latest Posix specification. 4. References 6815302 Implement futimens, utimensat(POSIX.1-2008) - set file modification times with nanosecond granularity 5. Manual pages. See the materials directory for the futimens(2) manual page. This is copied from the Posix specification, with minor changes such as changing "shall" to "will" in the text. Roger Faulkner From gdamore@sun.com Thu Aug 20 21:29:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7L4TIj2000078 for ; Thu, 20 Aug 2009 21:29:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7L4T9cu007765 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 21 Aug 2009 12:29:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOP00E05LSR1W00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Aug 2009 21:29:15 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOP003DRLSRHP50@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Aug 2009 21:29:15 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7L4TF5o006889 for ; Thu, 20 Aug 2009 21:29:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOP00500LQFB700@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Aug 2009 21:29:15 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOP0004YLSQW7A0@fe-sfbay-10.sun.com>; Thu, 20 Aug 2009 21:29:15 -0700 (PDT) Date: Thu, 20 Aug 2009 21:29:14 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com Message-id: <4A8E229A.2080600@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2409 An obvious +1. Thanks! - Garrett Roger A. Faulkner wrote: > I am sponsoring this automatic case for myself. > > 1. Introduction > > This case adds two new functions to the C library, > futimens() and utimensat(), as follows: > > #include > > int futimens(int fd, const struct timespec times[2]); > > int utimensat(int fd, const char *path, > const struct timespec times[2], int flag); > > The commitment level of these interfaces is Committed. > > The release binding is "patch" > (so it can be back-ported to Solaris 10 if required). > > 2. Discussion > > Problems with, for example, make on ZFS file systems have > emerged because ZFS keeps access and modification times for > its files with nanosecond granularity, while commands such > as touch(1) will only set access and modification times of > its target files to microsecond granularity (rounded down). > See the bugid: > > 6539657 touch(1) does not set the nanosecond timestamp > of a file correctly > > The touch(1) command (and possibly others) need a system call > interface that sets access and modification times of files > with nanosecond granularity. > > Happily, such interfaces have been designed and are specified > in the latest SUSv4 Posix interface specification: > > #include > > int futimens(int fd, const struct timespec times[2]); > > int utimensat(int fd, const char *path, > const struct timespec times[2], int flag); > > Even though Solaris does not (yet) implement the new Posix > standard, there is nothing stopping Solaris from providing > a few of the newly-specified interfaces (provided that the > names are appropriately hidden from view when an old > standards-conforming application is compiled). > > 3. Interface table > > Both functions are Committed. > Both are specified by the latest Posix specification. > > 4. References > > 6815302 Implement futimens, utimensat(POSIX.1-2008) - > set file modification times with nanosecond granularity > > 5. Manual pages. > > See the materials directory for the futimens(2) manual page. > This is copied from the Posix specification, with minor changes > such as changing "shall" to "will" in the text. > > Roger Faulkner > > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Aug 20 23:39:48 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7L6dmtK002087 for ; Thu, 20 Aug 2009 23:39:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7L6dmf8017347 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 20 Aug 2009 23:39:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOP00901RUCC300@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Aug 2009 23:39:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOP0077ORUBR510@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 20 Aug 2009 23:39:48 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7L6bHT6003639 for ; Fri, 21 Aug 2009 06:39:47 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-800195 for psarc-ext@sun.com; Fri, 21 Aug 2009 06:39:47 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-1487900 for psarc-ext@sun.com; Fri, 21 Aug 2009 06:39:46 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-17546644 for psarc-ext@sun.com; Fri, 21 Aug 2009 06:39:46 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id D25A5160043; Fri, 21 Aug 2009 08:39:44 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 4C30F160036; Fri, 21 Aug 2009 08:39:42 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7L6dgRw011870; Fri, 21 Aug 2009 08:39:42 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Aug 2009 08:39:42 +0200 Date: Fri, 21 Aug 2009 08:39:00 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <4A8E229A.2080600@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Roger.Faulkner@sun.com, gdamore@sun.com Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Bart.Smaalders@sun.com Message-id: <4a8e4104.1LT8sx//O+1jb8jF%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> <4A8E229A.2080600@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 21 Aug 2009 06:39:42.0513 (UTC) FILETIME=[2A2E5210:01CA222A] Status: RO Content-Length: 1219 To: gdamore@sun.com, Roger.Faulkner@sun.com Cc: Bart.Smaalders@sun.com, Darrin.Johnson@sun.com, Krister.Johansen@sun.com, Pavel.Filipensky@sun.com, psarc-ext@sun.com Subject: Re: PSARC/2009/453 - futimens, utimensat "Garrett D'Amore" wrote: > An obvious +1. Thanks! > > - Garrett > > Roger A. Faulkner wrote: > > I am sponsoring this automatic case for myself. > > > > 1. Introduction > > > > This case adds two new functions to the C library, > > futimens() and utimensat(), as follows: > > > > #include > > > > int futimens(int fd, const struct timespec times[2]); > > > > int utimensat(int fd, const char *path, > > const struct timespec times[2], int flag); In order to allow programs like star to be able to work correctly, we yould also need to have a pathconf()/fpathconf() call to retrieve the _actual_ resolution of a filesystem. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From lists@mcintyreweb.com Fri Aug 21 00:08:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7L783HD008630 for ; Fri, 21 Aug 2009 00:08:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7L77ujC006370; Fri, 21 Aug 2009 08:07:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOP00D01T5A7G00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 00:07:58 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOP0070WT59R940@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 00:07:58 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7L738td004414; Fri, 21 Aug 2009 07:07:57 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-3066269; Fri, 21 Aug 2009 07:07:57 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-1233434; Fri, 21 Aug 2009 07:07:50 +0000 (Z) Received: from remote.mcintyreweb.com ([67.23.1.228] [67.23.1.228]) by relay4i.sun.com with ESMTP id BT-MMP-1178941; Fri, 21 Aug 2009 07:01:25 +0000 (Z) Received: from twins.i.mcintyreweb.com (unknown [64.166.3.74]) by remote.mcintyreweb.com (Postfix) with ESMTPS id 5C56E10C275; Fri, 21 Aug 2009 00:01:19 -0700 (PDT) Date: Fri, 21 Aug 2009 00:00:53 -0700 From: Hugh McIntyre Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <4a8e4104.1LT8sx//O+1jb8jF%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling Cc: Roger.Faulkner@sun.com, gdamore@sun.com, psarc-ext@sun.com, Bart.Smaalders@sun.com, Pavel.Filipensky@sun.com, darrin.johnson@sun.com, krister.johansen@sun.com Message-id: <4A8E4625.9010202@mcintyreweb.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.377sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> <4A8E229A.2080600@sun.com> <4a8e4104.1LT8sx//O+1jb8jF%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 679 Joerg Schilling wrote: >>> int futimens(int fd, const struct timespec times[2]); >>> >>> int utimensat(int fd, const char *path, >>> const struct timespec times[2], int flag); > > In order to allow programs like star to be able to work correctly, we would > also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > resolution of a filesystem. It looks like there's already a standard for this (perhaps just proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. See http://www.theopengroup.org/austin/mailarchives/ag/msg10489.html and http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html Hugh. From dcragun@sonic.net Fri Aug 21 10:51:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LHpAt0005325 for ; Fri, 21 Aug 2009 10:51:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7LHp7cl014428; Fri, 21 Aug 2009 10:51:08 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00C09MX5KS00@nwk-avmta-2.sfbay.sun.com>; Fri, 21 Aug 2009 10:51:05 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00BS2MX1BU90@nwk-avmta-2.sfbay.sun.com>; Fri, 21 Aug 2009 10:51:05 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7LHjoPq025519; Fri, 21 Aug 2009 17:51:01 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-672128; Fri, 21 Aug 2009 17:51:00 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-2585331; Fri, 21 Aug 2009 17:51:00 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-18721879; Fri, 21 Aug 2009 17:51:00 +0000 (Z) Received: from webmail.sonic.net (b.webmail.sonic.net [64.142.100.148]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n7LHoxTV028535; Fri, 21 Aug 2009 10:50:59 -0700 Received: from 76.191.129.144 (SquirrelMail authenticated user dcragun) by webmail.sonic.net with HTTP; Fri, 21 Aug 2009 10:50:59 -0700 (PDT) Date: Fri, 21 Aug 2009 10:50:59 -0700 (PDT) From: Don Cragun Subject: Re: PSARC/2009/453 - futimens, utimensat To: Roger.Faulkner@sun.com, lists@mcintyreweb.com Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Message-id: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== User-Agent: SquirrelMail/1.4.9a Status: RO Content-Length: 1062 On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > Joerg Schilling wrote: > >>> >>> int futimens(int fd, const struct timespec times[2]); > >>> >>> > >>> >>> int utimensat(int fd, const char *path, > >>> >>> const struct timespec times[2], int flag); > > > > > > In order to allow programs like star to be able to work correctly, we would > > > also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > > > resolution of a filesystem. > > It looks like there's already a standard for this (perhaps just > proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. These are not just proposed; tHey were added to the standards at the same time futimens() and utimensat() were added. I believe this project is incomplete without also adding support for these to the fpathconf() and pathconf() functions and the getconf utility. - Don > > See http://www.theopengroup.org/austin/mailarchives/ag/msg10489.html and > http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html > > Hugh. From roland.mainz@nrubsig.org Fri Aug 21 11:08:03 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LI83C1006710 for ; Fri, 21 Aug 2009 11:08:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7LI81mc010271; Fri, 21 Aug 2009 11:08:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00601NPCSM00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 11:08:00 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00H9LNPCNM90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 11:08:00 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7LHw1hM010125; Fri, 21 Aug 2009 18:07:59 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-762414; Fri, 21 Aug 2009 18:07:59 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-2614651; Fri, 21 Aug 2009 18:07:59 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay1i.sun.com with ESMTP id BT-MMP-18358050; Fri, 21 Aug 2009 18:07:59 +0000 (Z) Received: from mail-in-05-z2.arcor-online.net (mail-in-05-z2.arcor-online.net [151.189.8.17]) by mx.arcor.de (Postfix) with ESMTP id D0DF41B3A29; Fri, 21 Aug 2009 20:07:57 +0200 (CEST) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mail-in-05-z2.arcor-online.net (Postfix) with ESMTP id C20C52DAFFA; Fri, 21 Aug 2009 20:07:57 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-223-167.pools.arcor-ip.net [94.219.223.167]) by mail-in-09.arcor-online.net (Postfix) with ESMTPS id 440AB1AF6CA; Fri, 21 Aug 2009 20:07:56 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n7LI7rxa000810; Fri, 21 Aug 2009 20:07:53 +0200 (CEST) Date: Fri, 21 Aug 2009 20:07:53 +0200 From: Roland Mainz Subject: Re: PSARC/2009/453 - futimens, utimensat Sender: gisburn@jupiterb48.nrubsig.org To: Don Cragun Cc: Roger.Faulkner@sun.com, lists@mcintyreweb.com, psarc-ext@sun.com, Bart.Smaalders@sun.com, Pavel.Filipensky@sun.com Message-id: <4A8EE279.70AE2584@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-09.arcor-online.net 440AB1AF6CA References: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> Status: RO Content-Length: 1302 Don Cragun wrote: > On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > > Joerg Schilling wrote: > > >>> >>> int futimens(int fd, const struct timespec times[2]); > > >>> >>> > > >>> >>> int utimensat(int fd, const char *path, > > >>> >>> const struct timespec times[2], int flag); > > > > > > > > In order to allow programs like star to be able to work correctly, we would > > > > also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > > > > resolution of a filesystem. > > > > It looks like there's already a standard for this (perhaps just > > proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. > > These are not just proposed; tHey were added to the standards at the > same time futimens() and utimensat() were added. > > I believe this project is incomplete without also adding support for > these to the fpathconf() and pathconf() functions and the getconf > utility. I agree with Don - we need a properly to detect such support on a filesystem level, otherwise there will be some difficulties to use these APIs in normal applications. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From gdamore@sun.com Fri Aug 21 11:46:26 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LIkPx7008885 for ; Fri, 21 Aug 2009 11:46:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7LIkLAR017648 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 21 Aug 2009 19:46:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00K0DPHABK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Aug 2009 12:46:22 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00AVMPH0EC50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Aug 2009 12:46:21 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7LIkCG1029149 for ; Fri, 21 Aug 2009 11:46:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOQ00500PARQS00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Aug 2009 11:46:12 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOQ002FOPGZ8E20@fe-sfbay-10.sun.com>; Fri, 21 Aug 2009 11:46:11 -0700 (PDT) Date: Fri, 21 Aug 2009 11:46:11 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> Sender: Garrett.Damore@sun.com To: Don Cragun Cc: Roger.Faulkner@sun.com, lists@mcintyreweb.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Message-id: <4A8EEB73.5090400@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1557 Don Cragun wrote: > On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > >> Joerg Schilling wrote: >> >>>>>>>> int futimens(int fd, const struct timespec times[2]); >>>>>>>> >>>>>>>> int utimensat(int fd, const char *path, >>>>>>>> const struct timespec times[2], int flag); >>>>>>>> >>>> In order to allow programs like star to be able to work correctly, we would >>>> also need to have a pathconf()/fpathconf() call to retrieve the _actual_ >>>> resolution of a filesystem. >>>> >> It looks like there's already a standard for this (perhaps just >> proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. >> > > These are not just proposed; tHey were added to the standards at the > same time futimens() and utimensat() were added. > > I believe this project is incomplete without also adding support for > these to the fpathconf() and pathconf() functions and the getconf > utility. > Hm.... it seems that these should definitely be added. I'm happy for them to be added to this project, but I'm not sure it is *required*. Indeed, the pathconf/fpathconf changes should probably have been made at the time ZFS introduced nanosecond resolution. So while there is a relationship here, I'm not sure that the projects are necessarily locked together. - Garrett > - Don > > >> See http://www.theopengroup.org/austin/mailarchives/ag/msg10489.html and >> http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html >> >> Hugh. >> > > > From roland.mainz@nrubsig.org Fri Aug 21 12:05:43 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LJ5gDD027233 for ; Fri, 21 Aug 2009 12:05:43 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7LJ5Y0c000458; Sat, 22 Aug 2009 03:05:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00H0LQDAWJ00@nwk-avmta-2.sfbay.sun.com>; Fri, 21 Aug 2009 12:05:34 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00DQJQDA8830@nwk-avmta-2.sfbay.sun.com>; Fri, 21 Aug 2009 12:05:34 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7LIlVrp006977; Fri, 21 Aug 2009 19:05:33 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-767452; Fri, 21 Aug 2009 19:05:33 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-404938; Fri, 21 Aug 2009 19:05:33 +0000 (Z) Received: from mail-in-02.arcor-online.net ([151.189.21.42] [151.189.21.42]) by relay1i.sun.com with ESMTP id BT-MMP-7370879; Fri, 21 Aug 2009 19:05:32 +0000 (Z) Received: from mail-in-17-z2.arcor-online.net (mail-in-17-z2.arcor-online.net [151.189.8.34]) by mx.arcor.de (Postfix) with ESMTP id 49B4C3FE0A9; Fri, 21 Aug 2009 21:05:31 +0200 (CEST) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-17-z2.arcor-online.net (Postfix) with ESMTP id 3C5B545C283; Fri, 21 Aug 2009 21:05:31 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-223-167.pools.arcor-ip.net [94.219.223.167]) by mail-in-16.arcor-online.net (Postfix) with ESMTPS id 49680257349; Fri, 21 Aug 2009 21:05:29 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n7LJ5QPJ000902; Fri, 21 Aug 2009 21:05:27 +0200 (CEST) Date: Fri, 21 Aug 2009 21:05:26 +0200 From: Roland Mainz Subject: Re: PSARC/2009/453 - futimens, utimensat Sender: gisburn@jupiterb48.nrubsig.org To: "Garrett D'Amore" Cc: Don Cragun , Bart.Smaalders@sun.com, psarc-ext@sun.com, Roger.Faulkner@sun.com, Pavel.Filipensky@sun.com Message-id: <4A8EEFF6.DCB8653@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-16.arcor-online.net 49680257349 References: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> <4A8EEB73.5090400@sun.com> Status: RO Content-Length: 1902 Garrett D'Amore wrote: > Don Cragun wrote: > > On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > >> Joerg Schilling wrote: > >>>>>>>> int futimens(int fd, const struct timespec times[2]); > >>>>>>>> > >>>>>>>> int utimensat(int fd, const char *path, > >>>>>>>> const struct timespec times[2], int flag); > >>>>>>>> > >>>> In order to allow programs like star to be able to work correctly, we would > >>>> also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > >>>> resolution of a filesystem. > >>>> > >> It looks like there's already a standard for this (perhaps just > >> proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. > > > > These are not just proposed; tHey were added to the standards at the > > same time futimens() and utimensat() were added. > > > > I believe this project is incomplete without also adding support for > > these to the fpathconf() and pathconf() functions and the getconf > > utility. > > Hm.... it seems that these should definitely be added. I'm happy for > them to be added to this project, but I'm not sure it is *required*. I think it is required since otherwise there is no good way to know why the timestamp changed between "set" and "get" ... > Indeed, the pathconf/fpathconf changes should probably have been made at > the time ZFS introduced nanosecond resolution. Doesn't tmpfs have nanosecond resolution since a long time ? > So while there is a relationship here, I'm not sure that the projects > are necessarily locked together. I think these are indirectly locked together and this issue needs to be fixed - otherwise there's no way to use the proposed API correctly for some applications. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From dcragun@sonic.net Fri Aug 21 12:17:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LJHlXN017457 for ; Fri, 21 Aug 2009 12:17:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7LJHRQf006443; Sat, 22 Aug 2009 03:17:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00G01QXH5Y00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 12:17:41 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00H1ZQXGNFD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 Aug 2009 12:17:41 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7LJ7ZWT005567; Fri, 21 Aug 2009 19:17:40 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-13232; Fri, 21 Aug 2009 19:17:40 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-1734314; Fri, 21 Aug 2009 19:17:27 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-225104; Fri, 21 Aug 2009 19:02:47 +0000 (Z) Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n7LJ1mim026755; Fri, 21 Aug 2009 12:01:48 -0700 Date: Fri, 21 Aug 2009 12:01:46 -0700 From: Don Cragun Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <4A8EEB73.5090400@sun.com> To: "Garrett D'Amore" Cc: Roger.Faulkner@sun.com, lists@mcintyreweb.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Message-id: <4A8EEF1A.4070305@sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.180sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <19716.76.191.129.144.1250877059.squirrel@webmail.sonic.net> <4A8EEB73.5090400@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 1509 Garrett D'Amore wrote: > Don Cragun wrote: >> On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: >> ... ... ... >> >> I believe this project is incomplete without also adding support for >> these to the fpathconf() and pathconf() functions and the getconf >> utility. >> > > Hm.... it seems that these should definitely be added. I'm happy for > them to be added to this project, but I'm not sure it is *required*. > > Indeed, the pathconf/fpathconf changes should probably have been made at > the time ZFS introduced nanosecond resolution. I don't remember exactly when ZFS introduced nanosecond resulution, but I don't think the changes being presented here for [f]pathconf() were in the standard at that time. Normally, this would be added when the SUSv4 conformance project is added to the system, ... but I haven't heard of any plans for that project since I left Sun. From the outside, it appears that Sun is picking up some pieces of the standard without plans to implement full conformance to the standard. ;-{ If that is the case, I think it is important to be sure that these connected pieces of the standard are all implemented as a single project. - Don > > So while there is a relationship here, I'm not sure that the projects > are necessarily locked together. > > - Garrett >> - Don >> >> >>> See http://www.theopengroup.org/austin/mailarchives/ag/msg10489.html and >>> http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html >>> >>> Hugh. From Roger.Faulkner@sun.com Sun Aug 23 21:56:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7O4uYIg012900 for ; Sun, 23 Aug 2009 21:56:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7O4uVjl028907; Sun, 23 Aug 2009 21:56:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOV00D077279900@brm-avmta-1.central.sun.com>; Sun, 23 Aug 2009 22:56:31 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOV005M9727JD70@brm-avmta-1.central.sun.com>; Sun, 23 Aug 2009 22:56:31 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7O4uUSu152314; Sun, 23 Aug 2009 21:56:30 -0700 (PDT) Date: Sun, 23 Aug 2009 21:56:30 -0700 (PDT) From: "Roger A. Faulkner" Subject: Re: PSARC/2009/453 - futimens, utimensat To: gdamore@sun.com, dcragun@sonic.net Cc: lists@mcintyreweb.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Reply-to: "Roger A. Faulkner" Message-id: <200908240456.n7O4uUSu152314@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_116 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: +JkAYvGA+ugD3jeZN18hsw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2798 > Date: Fri, 21 Aug 2009 12:01:46 -0700 > From: Don Cragun > Subject: Re: PSARC/2009/453 - futimens, utimensat > To: "Garrett D'Amore" > Cc: Roger.Faulkner@sun.com, lists@mcintyreweb.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com > X-Brightmail-Tracker: AAAAAA== > X-Antispam: No, score=0.0/5.0, scanned in 2.180sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ > > Garrett D'Amore wrote: > > Don Cragun wrote: > >> On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: > >> > ... ... ... > >> > >> I believe this project is incomplete without also adding support for > >> these to the fpathconf() and pathconf() functions and the getconf > >> utility. > >> > > > > Hm.... it seems that these should definitely be added. I'm happy for > > them to be added to this project, but I'm not sure it is *required*. > > > > Indeed, the pathconf/fpathconf changes should probably have been made at > > the time ZFS introduced nanosecond resolution. > > I don't remember exactly when ZFS introduced nanosecond resulution, but > I don't think the changes being presented here for [f]pathconf() were in > the standard at that time. Normally, this would be added when the SUSv4 > conformance project is added to the system, ... but I haven't heard of > any plans for that project since I left Sun. From the outside, it > appears that Sun is picking up some pieces of the standard without plans > to implement full conformance to the standard. ;-{ If that is the > case, I think it is important to be sure that these connected pieces of > the standard are all implemented as a single project. > > - Don 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. 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. 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 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? Roger From dcragun@sonic.net Sun Aug 23 22:18:26 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7O5IQj1013420 for ; Sun, 23 Aug 2009 22:18:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7O5IOFg004726; Sun, 23 Aug 2009 22:18:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOV00D0D82N0F00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 23 Aug 2009 22:18:23 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOV002ON82MIFB0@nwk-avmta-1.sfbay.Sun.COM>; Sun, 23 Aug 2009 22:18:22 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7O5Cn9Z021990; Mon, 24 Aug 2009 05:18:22 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-1010724; Mon, 24 Aug 2009 05:18:21 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-8060528; Mon, 24 Aug 2009 05:18:20 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay1i.sun.com with ESMTP id BT-MMP-26852568; Mon, 24 Aug 2009 05:18:20 +0000 (Z) Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n7O5IJcd011432; Sun, 23 Aug 2009 22:18:19 -0700 Date: Sun, 23 Aug 2009 22:18:16 -0700 From: Don Cragun Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908240456.n7O4uUSu152314@jurassic-x4600.sfbay.sun.com> To: "Roger A. Faulkner" Cc: gdamore@sun.com, lists@mcintyreweb.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Message-id: <4A922298.6070704@sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200908240456.n7O4uUSu152314@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 2908 On Fri, 21 Aug 2009 12:01:46 -0700, Roger A. Faulkner wrote: >> Garrett D'Amore wrote: >>> Don Cragun wrote: >>>> On Fri, 21 Aug 2009 00:00:53 -0700, Hugh McIntyre wrote: >>>> >> ... ... ... >>>> I believe this project is incomplete without also adding support for >>>> these to the fpathconf() and pathconf() functions and the getconf >>>> utility. >>>> >>> Hm.... it seems that these should definitely be added. I'm happy for >>> them to be added to this project, but I'm not sure it is *required*. >>> >>> Indeed, the pathconf/fpathconf changes should probably have been made at >>> the time ZFS introduced nanosecond resolution. >> I don't remember exactly when ZFS introduced nanosecond resulution, but >> I don't think the changes being presented here for [f]pathconf() were in >> the standard at that time. Normally, this would be added when the SUSv4 >> conformance project is added to the system, ... but I haven't heard of >> any plans for that project since I left Sun. From the outside, it >> appears that Sun is picking up some pieces of the standard without plans >> to implement full conformance to the standard. ;-{ If that is the >> case, I think it is important to be sure that these connected pieces of >> the standard are all implemented as a single project. >> >> - Don > > 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. > > 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. > > 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 > > 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? Yes. It sounds to me like you have done the "right thing" here. One of the meanings of EINVAL listed in the standard is "The implementation does not support an association of the variable name with the specified file." and you're saying that NFS doesn't support an association of TIMESTAMP_RESOLUTION with NFS mounted files. However, please also file a bug against NFS asking that the protocol be extended to provide this information. Thanks, Don > > Roger From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon Aug 24 11:00:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7OI0hAc025995 for ; Mon, 24 Aug 2009 11:00:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7OI0Ykj014290 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 25 Aug 2009 02:00:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOW008017D61900@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Aug 2009 11:00:42 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOW005HK7D50J30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Aug 2009 11:00:42 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7OHr7LQ025527 for ; Mon, 24 Aug 2009 18:00:41 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-986896 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:00:37 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-9663825 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:00:36 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-26222396 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:00:36 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 9B7A594151; Mon, 24 Aug 2009 19:59:44 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id CDA0D9413C; Mon, 24 Aug 2009 19:59:41 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7OHxfcV025171; Mon, 24 Aug 2009 19:59:41 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 19:59:41 +0200 Date: Mon, 24 Aug 2009 19:58:56 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <4A8E4625.9010202@mcintyreweb.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: lists@mcintyreweb.com Cc: Roger.Faulkner@sun.com, psarc-ext@sun.com, Pavel.Filipensky@sun.com, Krister.Johansen@sun.com, gdamore@sun.com, Darrin.Johnson@sun.com, Bart.Smaalders@sun.com Message-id: <4a92d4e0.RPdktT4o6AGc2VXn%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200908210259.n7L2xrvO341539@jurassic-x4600.sfbay.sun.com> <4A8E229A.2080600@sun.com> <4a8e4104.1LT8sx//O+1jb8jF%Joerg.Schilling@fokus.fraunhofer.de> <4A8E4625.9010202@mcintyreweb.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 24 Aug 2009 17:59:41.0442 (UTC) FILETIME=[A77A1620:01CA24E4] Status: RO Content-Length: 1111 Hugh McIntyre wrote: > Joerg Schilling wrote: > >>> int futimens(int fd, const struct timespec times[2]); > >>> > >>> int utimensat(int fd, const char *path, > >>> const struct timespec times[2], int flag); > > > > In order to allow programs like star to be able to work correctly, we would > > also need to have a pathconf()/fpathconf() call to retrieve the _actual_ > > resolution of a filesystem. > > It looks like there's already a standard for this (perhaps just > proposed?): _POSIX_TIMESTAMP_RESOLUTION and _PC_TIMESTAMP_RESOLUTION. > > See http://www.theopengroup.org/austin/mailarchives/ag/msg10489.html and > http://www.opengroup.org/onlinepubs/9699919799/functions/fpathconf.html Thank you for the hint! I forgot that my proposal was accepted ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon Aug 24 11:18:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7OIILvI026693 for ; Mon, 24 Aug 2009 11:18:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7OIIFYb023787 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 25 Aug 2009 02:18:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOW00M0386HZY00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Aug 2009 11:18:17 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOW00DA786GGAC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 24 Aug 2009 11:18:17 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7OIAn5R004438 for ; Mon, 24 Aug 2009 18:18:16 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-900306 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:18:13 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-455497 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:18:13 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-28572349 for psarc-ext@sun.com; Mon, 24 Aug 2009 18:18:12 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id B160616000E; Mon, 24 Aug 2009 20:18:11 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 996299411F; Mon, 24 Aug 2009 20:18:09 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7OII9kl025405; Mon, 24 Aug 2009 20:18:09 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 20:18:09 +0200 Date: Mon, 24 Aug 2009 20:17:24 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908240456.n7O4uUSu152314@jurassic-x4600.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Roger.Faulkner@sun.com, gdamore@sun.com, dcragun@sonic.net Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com Message-id: <4a92d934.ysQFShJ0xc+EjwCq%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200908240456.n7O4uUSu152314@jurassic-x4600.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 24 Aug 2009 18:18:09.0408 (UTC) FILETIME=[3BE04800:01CA24E7] Status: RO Content-Length: 2109 "Roger A. Faulkner" 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@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Roger.Faulkner@sun.com Thu Aug 27 12:58:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RJwaNj020016 for ; Thu, 27 Aug 2009 12:58:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7RJwVd7004046; Thu, 27 Aug 2009 20:58:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP100G09WTJ4700@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 13:58:31 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP100M25WTIOND0@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 13:58:30 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7RJw53v450891; Thu, 27 Aug 2009 12:58:05 -0700 (PDT) Date: Thu, 27 Aug 2009 12:58:05 -0700 (PDT) From: "Roger A. Faulkner" Subject: Re: PSARC/2009/453 - futimens, utimensat To: psarc-ext@sun.com Cc: Pavel.Filipensky@sun.com, bart.smaalders@sun.com, krister.johansen@sun.com, darrin.johnson@sun.com, gdamore@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Reply-to: "Roger A. Faulkner" Message-id: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_116 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: W1PZN46GXVGoBLRjkeW+wA== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3717 In response to the e-mail discussion of this case, I am submitting this revised specification: futimens, utimensat 1. Introduction This case adds two new functions to the C library, futimens() and utimensat(), as follows: #include int futimens(int fd, const struct timespec times[2]); int utimensat(int fd, const char *path, const struct timespec times[2], int flag); In addition, in order to query the timestamp resolution for a given file or directory, fpathconf() and pathconf() will be extended to accept a new name, _PC_TIMESTAMP_RESOLUTION, defined in . The return value of fpathconf() and pathconf() in this case will be a number in the range 1 to 1000 million, indicating the number of nanoseconds of the file's timestamp resolution. Each local file system will be made to understand this new VOP_PATHCONF operation and return the appropriate value. Finally, the touch(1) utility will be updated to use the new interfaces and to provide a date_time specification that includes up to nanosecond resolution. The commitment level of these interfaces is Committed. The release binding is "patch" (so it can be back-ported to Solaris 10 if required). 2. Discussion Problems with, for example, make on ZFS file systems have emerged because ZFS keeps access and modification times for its files with nanosecond granularity, while commands such as touch(1) will only set access and modification times of its target files to microsecond granularity (rounded down). See the bugid: 6539657 touch(1) does not set the nanosecond timestamp of a file correctly The touch(1) command (and possibly others) need a system call interface that sets access and modification times of files with nanosecond granularity. Happily, such interfaces have been designed and are specified in the latest SUSv4 Posix interface specification: #include int futimens(int fd, const struct timespec times[2]); int utimensat(int fd, const char *path, const struct timespec times[2], int flag); Even though Solaris does not (yet) implement the new Posix standard, there is nothing stopping Solaris from providing a few of the newly-specified interfaces (provided that the names are appropriately hidden from view when an old standards-conforming application is compiled). 3. Interface table The futimens() and utimensat() functions are Committed. Both are specified by the latest Posix specification. The fpathconf() name _PC_TIMESTAMP_RESOLUTION and operation are Committed and are specified by the latest Posix specification. The updated touch(1) command line interface is Committed and is specified by the latest Posix specification. 4. References 6815302 Implement futimens, utimensat(POSIX.1-2008) - set file modification times with nanosecond granularity 5. Manual pages. See the materials directory for the new futimens(2) manual page. This is copied from the Posix specification, with minor changes such as changing "shall" to "will" in the text. See the subdirectories 'oldman' and 'newman' under the materials directory to view the old and new manual pages for getconf.1 touch.1 pathconf.2 utime.2 utimes.2 stat.h.3head unistd.h.3head The 'newman' files contain modifications reflecting the changes described in this proposal. Use 'diff' to view the differences between the old and new manual pages. Roger Faulkner From gdamore@sun.com Thu Aug 27 13:02:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RK2xix020192 for ; Thu, 27 Aug 2009 13:02:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7RK2pKB007155 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 27 Aug 2009 21:02:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP100D0NX0WBK00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 13:02:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP1004CQX0UEEF0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 13:02:55 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7RK2sIU025679 for ; Thu, 27 Aug 2009 13:02:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KP100J00WUHC100@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 13:02:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KP100948X0SU6E0@fe-sfbay-10.sun.com>; Thu, 27 Aug 2009 13:02:53 -0700 (PDT) Date: Thu, 27 Aug 2009 13:02:52 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Roger A. Faulkner" Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Message-id: <4A96E66C.5000207@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4107 +1 on the revised spec. It seems like (not this project) someone ought to pursue getting support for high resolution timestamps into the next NFS specification. - Garrett Roger A. Faulkner wrote: > In response to the e-mail discussion of this case, > I am submitting this revised specification: > > futimens, utimensat > > 1. Introduction > > This case adds two new functions to the C library, > futimens() and utimensat(), as follows: > > #include > > int futimens(int fd, const struct timespec times[2]); > > int utimensat(int fd, const char *path, > const struct timespec times[2], int flag); > > In addition, in order to query the timestamp resolution for > a given file or directory, fpathconf() and pathconf() will > be extended to accept a new name, _PC_TIMESTAMP_RESOLUTION, > defined in . The return value of fpathconf() > and pathconf() in this case will be a number in the range > 1 to 1000 million, indicating the number of nanoseconds > of the file's timestamp resolution. Each local file system > will be made to understand this new VOP_PATHCONF operation > and return the appropriate value. > > Finally, the touch(1) utility will be updated to use the > new interfaces and to provide a date_time specification > that includes up to nanosecond resolution. > > The commitment level of these interfaces is Committed. > > The release binding is "patch" > (so it can be back-ported to Solaris 10 if required). > > 2. Discussion > > Problems with, for example, make on ZFS file systems have > emerged because ZFS keeps access and modification times for > its files with nanosecond granularity, while commands such > as touch(1) will only set access and modification times of > its target files to microsecond granularity (rounded down). > See the bugid: > > 6539657 touch(1) does not set the nanosecond timestamp > of a file correctly > > The touch(1) command (and possibly others) need a system call > interface that sets access and modification times of files > with nanosecond granularity. > > Happily, such interfaces have been designed and are specified > in the latest SUSv4 Posix interface specification: > > #include > > int futimens(int fd, const struct timespec times[2]); > > int utimensat(int fd, const char *path, > const struct timespec times[2], int flag); > > Even though Solaris does not (yet) implement the new Posix > standard, there is nothing stopping Solaris from providing > a few of the newly-specified interfaces (provided that the > names are appropriately hidden from view when an old > standards-conforming application is compiled). > > 3. Interface table > > The futimens() and utimensat() functions are Committed. > Both are specified by the latest Posix specification. > > The fpathconf() name _PC_TIMESTAMP_RESOLUTION and operation are > Committed and are specified by the latest Posix specification. > > The updated touch(1) command line interface is Committed > and is specified by the latest Posix specification. > > 4. References > > 6815302 Implement futimens, utimensat(POSIX.1-2008) - > set file modification times with nanosecond granularity > > 5. Manual pages. > > See the materials directory for the new futimens(2) manual page. > This is copied from the Posix specification, with minor changes > such as changing "shall" to "will" in the text. > > See the subdirectories 'oldman' and 'newman' under the > materials directory to view the old and new manual pages for > getconf.1 > touch.1 > pathconf.2 > utime.2 > utimes.2 > stat.h.3head > unistd.h.3head > The 'newman' files contain modifications reflecting the changes > described in this proposal. Use 'diff' to view the differences > between the old and new manual pages. > > Roger Faulkner > > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Aug 27 13:26:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RKQNwq021256 for ; Thu, 27 Aug 2009 13:26:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7RKPvDc003615 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 28 Aug 2009 04:26:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP100G07Y3XGZ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 13:26:21 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP100D8IY3WD730@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 13:26:21 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7RKFGBV000999 for ; Thu, 27 Aug 2009 20:26:20 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-36865 for psarc-ext@sun.com; Thu, 27 Aug 2009 20:26:18 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-7323211 for psarc-ext@sun.com; Thu, 27 Aug 2009 20:26:12 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-265415 for psarc-ext@sun.com; Thu, 27 Aug 2009 20:26:12 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 379CF6F05A5; Thu, 27 Aug 2009 22:26:11 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id F09D06F0586; Thu, 27 Aug 2009 22:26:07 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7RKQ7vk019590; Thu, 27 Aug 2009 22:26:07 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 22:26:07 +0200 Date: Thu, 27 Aug 2009 22:25:19 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Roger.Faulkner@sun.com, psarc-ext@sun.com Cc: roland.mainz@nrubsig.org, Pavel.Filipensky@sun.com, lists@mcintyreweb.com, krister.johansen@sun.com, gdamore@sun.com, dcragun@sonic.net, darrin.johnson@sun.com, bart.smaalders@sun.com Message-id: <4a96ebaf.gUFIlxqhc6SZghsV%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 6.014sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 27 Aug 2009 20:26:07.0620 (UTC) FILETIME=[9BAFB440:01CA2754] Status: RO Content-Length: 1547 "Roger A. Faulkner" wrote: > In response to the e-mail discussion of this case, > I am submitting this revised specification: > > futimens, utimensat > > 1. Introduction > > This case adds two new functions to the C library, > futimens() and utimensat(), as follows: > > #include > > int futimens(int fd, const struct timespec times[2]); > > int utimensat(int fd, const char *path, > const struct timespec times[2], int flag); > > In addition, in order to query the timestamp resolution for > a given file or directory, fpathconf() and pathconf() will > be extended to accept a new name, _PC_TIMESTAMP_RESOLUTION, > defined in . The return value of fpathconf() > and pathconf() in this case will be a number in the range > 1 to 1000 million, indicating the number of nanoseconds > of the file's timestamp resolution. Each local file system > will be made to understand this new VOP_PATHCONF operation > and return the appropriate value. IIRC, then the pcfs timestamps have a 2 second timestamp granularity for the mtime and a one day granularity for the atime. The latter cannot be represented in the pathconf() fcall. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Roger.Faulkner@Sun.COM Thu Aug 27 13:57:48 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RKvmqt022562 for ; Thu, 27 Aug 2009 13:57:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7RKviFq013249; Thu, 27 Aug 2009 13:57:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP100M0NZKA8400@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 14:57:46 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP100JRTZK9TU10@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 14:57:45 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7RKviCG475848; Thu, 27 Aug 2009 13:57:44 -0700 (PDT) Date: Thu, 27 Aug 2009 13:57:44 -0700 (PDT) From: "Roger A. Faulkner" Subject: Re: PSARC/2009/453 - futimens, utimensat To: psarc-ext@Sun.COM, Joerg.Schilling@fokus.fraunhofer.de Cc: roland.mainz@nrubsig.org, Pavel.Filipensky@Sun.COM, lists@mcintyreweb.com, krister.johansen@Sun.COM, gdamore@Sun.COM, dcragun@sonic.net, darrin.johnson@Sun.COM, bart.smaalders@Sun.COM Reply-to: "Roger A. Faulkner" Message-id: <200908272057.n7RKviCG475848@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_116 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=ISO-8859-1 Content-MD5: xTkBrhFV99F+I0gp2fIlwg== X-PMX-Version: 5.4.1.325704 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sac.sfbay.sun.com id n7RKvmqt022562 Status: RO Content-Length: 1912 > Date: Thu, 27 Aug 2009 22:25:19 +0200 > From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) > Subject: Re: PSARC/2009/453 - futimens, utimensat > To: Roger.Faulkner@sun.com, psarc-ext@sun.com > Cc: roland.mainz@nrubsig.org, Pavel.Filipensky@sun.com, lists@mcintyreweb.com, krister.johansen@sun.com, gdamore@sun.com, dcragun@sonic.net, darrin.johnson@sun.com, bart.smaalders@sun.com > > "Roger A. Faulkner" wrote: > > > In response to the e-mail discussion of this case, > > I am submitting this revised specification: > > > > futimens, utimensat > > > > 1. Introduction > > > > This case adds two new functions to the C library, > > futimens() and utimensat(), as follows: > > > > #include > > > > int futimens(int fd, const struct timespec times[2]); > > > > int utimensat(int fd, const char *path, > > const struct timespec times[2], int flag); > > > > In addition, in order to query the timestamp resolution for > > a given file or directory, fpathconf() and pathconf() will > > be extended to accept a new name, _PC_TIMESTAMP_RESOLUTION, > > defined in . The return value of fpathconf() > > and pathconf() in this case will be a number in the range > > 1 to 1000 million, indicating the number of nanoseconds > > of the file's timestamp resolution. Each local file system > > will be made to understand this new VOP_PATHCONF operation > > and return the appropriate value. > > IIRC, then the pcfs timestamps have a 2 second timestamp granularity > for the mtime and a one day granularity for the atime. > > The latter cannot be represented in the pathconf() fcall. > > Jörg Yeah, well... I just made pathconf(_PC_TIMESTAMP_RESOLUTION) return 1000 000 000 for pcfs. Is that good enough? Does anyone really care? Should I make it fail (-1 w/ EINVAL)? Roger From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Aug 27 14:21:36 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RLLaG9023307 for ; Thu, 27 Aug 2009 14:21:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7RLLZSE021807 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 27 Aug 2009 14:21:36 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP2000050O0P100@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 14:21:36 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200DZD0O0D970@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 27 Aug 2009 14:21:36 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7RLIr37012373 for ; Thu, 27 Aug 2009 21:21:35 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-30907 for psarc-ext@sun.com; Thu, 27 Aug 2009 21:21:35 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-178380 for psarc-ext@sun.com; Thu, 27 Aug 2009 21:21:31 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay4i.sun.com with ESMTP id BT-MMP-567075 for psarc-ext@sun.com; Thu, 27 Aug 2009 21:19:05 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 3C3DA160022; Thu, 27 Aug 2009 23:18:53 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 8A88716000E; Thu, 27 Aug 2009 23:18:50 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7RLIoJ2020367; Thu, 27 Aug 2009 23:18:50 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 23:18:50 +0200 Date: Thu, 27 Aug 2009 23:17:58 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908272057.n7RKviCG475848@jurassic-x4600.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Roger.Faulkner@sun.com, psarc-ext@sun.com Cc: roland.mainz@nrubsig.org, Pavel.Filipensky@sun.com, lists@mcintyreweb.com, krister.johansen@sun.com, gdamore@sun.com, dcragun@sonic.net, darrin.johnson@sun.com, bart.smaalders@sun.com Message-id: <4a96f806.b7HFScLE6sPUq/76%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 3.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908272057.n7RKviCG475848@jurassic-x4600.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 27 Aug 2009 21:18:50.0201 (UTC) FILETIME=[F8BB4490:01CA275B] Status: RO Content-Length: 1484 "Roger A. Faulkner" wrote: > > IIRC, then the pcfs timestamps have a 2 second timestamp granularity > > for the mtime and a one day granularity for the atime. > > > > The latter cannot be represented in the pathconf() fcall. > > > > Jörg > > Yeah, well... > > I just made pathconf(_PC_TIMESTAMP_RESOLUTION) return 1000 000 000 > for pcfs. Is that good enough? Does anyone really care? > Should I make it fail (-1 w/ EINVAL)? Star and cpio decide on the timestamp whether a file will be extracted or not. If pathconf(_PC_TIMESTAMP_RESOLUTION) returns 1000 000 000, star will probably make a wrong decision in future because a timestamp of 1000 may be a rounded down 1001. Star currently implements some heuristics but in case that pathconf(_PC_TIMESTAMP_RESOLUTION) will work, future versions will asume that the returned value is correct. 2 seconds may be represented by a 32 bit value. BTW: POSIX requires pathconf(_PC_TIMESTAMP_RESOLUTION) to return -1/EOVERFLOW in case of an number overflow. We would need to do this if we look at atime. I however tend to believe it is better not to return an overflow as mtime is more important than atime. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Nicolas.Williams@sun.com Thu Aug 27 14:53:33 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RLrXlu024131 for ; Thu, 27 Aug 2009 14:53:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7RLrRZ4021882; Thu, 27 Aug 2009 22:53:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP20050F2544G00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Aug 2009 14:53:28 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200DWN254D9A0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 27 Aug 2009 14:53:28 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7RKRdYG004336; Thu, 27 Aug 2009 15:27:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7RKRcww004335; Thu, 27 Aug 2009 15:27:38 -0500 (CDT) Date: Thu, 27 Aug 2009 15:27:38 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <4A96E66C.5000207@sun.com> To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , psarc-ext@sun.com, Pavel.Filipensky@sun.com, bart.smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Message-id: <20090827202738.GB1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> <4A96E66C.5000207@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 377 On Thu, Aug 27, 2009 at 01:02:52PM -0700, Garrett D'Amore wrote: > +1 on the revised spec. > > It seems like (not this project) someone ought to pursue getting support > for high resolution timestamps into the next NFS specification. Conveniently, the IETF NFSv4 WG is looking for work items for NFSv4.2. I've just sent a short note to the WG mailing list about this issue. From dcragun@sonic.net Thu Aug 27 14:55:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RLtiiX024401 for ; Thu, 27 Aug 2009 14:55:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7RLtfbl005455; Thu, 27 Aug 2009 14:55:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP20050928T7O00@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 15:55:41 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200JX728RTW40@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 15:55:39 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7RLkLZI015325; Thu, 27 Aug 2009 21:55:39 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-33329; Thu, 27 Aug 2009 21:55:30 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-172903; Thu, 27 Aug 2009 21:55:29 +0000 (Z) Received: from b.mail.sonic.net ([64.142.19.5] [64.142.19.5]) by relay4i.sun.com with ESMTP id BT-MMP-622036; Thu, 27 Aug 2009 21:55:29 +0000 (Z) Received: from [10.0.0.10] (76-191-129-144.dsl.dynamic.sonic.net [76.191.129.144]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id n7RLtOxT025620; Thu, 27 Aug 2009 14:55:24 -0700 Date: Thu, 27 Aug 2009 14:55:23 -0700 From: Don Cragun Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908272057.n7RKviCG475848@jurassic-x4600.sfbay.sun.com> To: "Roger A. Faulkner" Cc: psarc-ext@sun.com, Joerg.Schilling@fokus.fraunhofer.de, roland.mainz@nrubsig.org, Pavel.Filipensky@sun.com, lists@mcintyreweb.com, krister.johansen@sun.com, gdamore@sun.com, darrin.johnson@sun.com, bart.smaalders@sun.com Message-id: <4A9700CB.8070309@sonic.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.091sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908272057.n7RKviCG475848@jurassic-x4600.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 1353 On Thu, 27 Aug 2009 22:25:19 +0200, Roger A. Faulkner wrote: >> From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) >> "Roger A. Faulkner" wrote: >> ... ... ... >>> In addition, in order to query the timestamp resolution for >>> a given file or directory, fpathconf() and pathconf() will >>> be extended to accept a new name, _PC_TIMESTAMP_RESOLUTION, >>> defined in . The return value of fpathconf() >>> and pathconf() in this case will be a number in the range >>> 1 to 1000 million, indicating the number of nanoseconds >>> of the file's timestamp resolution. Each local file system >>> will be made to understand this new VOP_PATHCONF operation >>> and return the appropriate value. >> IIRC, then the pcfs timestamps have a 2 second timestamp granularity >> for the mtime and a one day granularity for the atime. >> >> The latter cannot be represented in the pathconf() fcall. >> >> Jörg > > Yeah, well... > > I just made pathconf(_PC_TIMESTAMP_RESOLUTION) return 1000 000 000 > for pcfs. Is that good enough? Does anyone really care? > Should I make it fail (-1 w/ EINVAL)? Hi Roger, The latest version of the standards say: "[EOVERFLOW] The value of name is _PC_TIMESTAMP_RESOLUTION and the resolution is larger than {LONG_MAX}." Cheers, Don > > Roger From Nicolas.Williams@sun.com Thu Aug 27 16:08:46 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7RN8k9q008086 for ; Thu, 27 Aug 2009 16:08:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7RN8icC011017; Thu, 27 Aug 2009 17:08:44 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP200C015MKWR00@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 17:08:44 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200JX55MJTZ90@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 17:08:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7RLZPCH004519; Thu, 27 Aug 2009 16:35:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7RLZPkf004518; Thu, 27 Aug 2009 16:35:25 -0500 (CDT) Date: Thu, 27 Aug 2009 16:35:25 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <20090827202738.GB1033@Sun.COM> To: "Garrett D'Amore" Cc: "Roger A. Faulkner" , psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Message-id: <20090827213524.GI1048@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908271958.n7RJw53v450891@jurassic-x4600.sfbay.sun.com> <4A96E66C.5000207@sun.com> <20090827202738.GB1033@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 643 On Thu, Aug 27, 2009 at 03:27:38PM -0500, Nicolas Williams wrote: > On Thu, Aug 27, 2009 at 01:02:52PM -0700, Garrett D'Amore wrote: > > +1 on the revised spec. > > > > It seems like (not this project) someone ought to pursue getting support > > for high resolution timestamps into the next NFS specification. > > Conveniently, the IETF NFSv4 WG is looking for work items for NFSv4.2. > I've just sent a short note to the WG mailing list about this issue. Actually, NFSv3 and NFSv4 already have this. I think our server just sets this to a constant, and our client doesn't use it. So just file a CR against solaris/kernel/nfs? Nico -- From Roger.Faulkner@sun.com Thu Aug 27 17:14:21 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7S0EL5D005472 for ; Thu, 27 Aug 2009 17:14:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7S0EGBW023131; Thu, 27 Aug 2009 17:14:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP200K0F8NU0W00@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 18:14:18 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP200JQ28NTTUE0@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 18:14:18 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (jurassic-x4600.sfbay.sun.com [129.146.17.63]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7S0EHCf588283; Thu, 27 Aug 2009 17:14:17 -0700 (PDT) Date: Thu, 27 Aug 2009 17:14:17 -0700 (PDT) From: "Roger A. Faulkner" Subject: Re: PSARC/2009/453 - futimens, utimensat To: gdamore@sun.com, Nicolas.Williams@sun.com Cc: psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Reply-to: "Roger A. Faulkner" Message-id: <200908280014.n7S0EHCf588283@jurassic-x4600.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_116 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: wl/mJAeIYcHvg0///w4fsw== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1707 > Date: Thu, 27 Aug 2009 16:35:25 -0500 > From: Nicolas Williams > Subject: Re: PSARC/2009/453 - futimens, utimensat > To: "Garrett D'Amore" > Cc: "Roger A. Faulkner" , psarc-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org > > On Thu, Aug 27, 2009 at 03:27:38PM -0500, Nicolas Williams wrote: > > On Thu, Aug 27, 2009 at 01:02:52PM -0700, Garrett D'Amore wrote: > > > +1 on the revised spec. > > > > > > It seems like (not this project) someone ought to pursue getting support > > > for high resolution timestamps into the next NFS specification. > > > > Conveniently, the IETF NFSv4 WG is looking for work items for NFSv4.2. > > I've just sent a short note to the WG mailing list about this issue. > > Actually, NFSv3 and NFSv4 already have this. I think our server just > sets this to a constant, and our client doesn't use it. > > So just file a CR against solaris/kernel/nfs? > > Nico I know that NFSv3 and NFSv4 send nanosecond-resolution timestamps over the wire. That's not the problemm. The problem is that the remotely-mounted file system may or may not honor such timestamps. For example, a remotely-mounted UFS file system will only honor microsecond-resolution timestamps. But the client side doesn't know that. It's just an NFS-mounted file system as far as the client knows. What is needed is a VOP_PATHCONF(_PC_TIMESTAMP_RESOLUTION) operation for NFS that returns the actual timestamp resolution for the underlying file system. Roger From Nicolas.Williams@sun.com Thu Aug 27 21:29:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7S4TmnZ016707 for ; Thu, 27 Aug 2009 21:29:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7S4TjAi052071; Thu, 27 Aug 2009 22:29:46 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KP20010FKHLV200@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 22:29:45 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KP2006MVKHLPRC0@brm-avmta-1.central.sun.com>; Thu, 27 Aug 2009 22:29:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7S2uP2Y004916; Thu, 27 Aug 2009 21:56:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7S2uPnH004915; Thu, 27 Aug 2009 21:56:25 -0500 (CDT) Date: Thu, 27 Aug 2009 21:56:24 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/453 - futimens, utimensat In-reply-to: <200908280014.n7S0EHCf588283@jurassic-x4600.sfbay.sun.com> To: "Roger A. Faulkner" Cc: gdamore@sun.com, PSARC-ext@sun.com, Pavel.Filipensky@sun.com, Bart.Smaalders@sun.com, Krister.Johansen@sun.com, Darrin.Johnson@sun.com, Joerg.Schilling@fokus.fraunhofer.de, lists@mcintyreweb.com, dcragun@sonic.net, roland.mainz@nrubsig.org Message-id: <20090828025624.GM1033@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908280014.n7S0EHCf588283@jurassic-x4600.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1167 On Thu, Aug 27, 2009 at 05:14:17PM -0700, Roger A. Faulkner wrote: > > Actually, NFSv3 and NFSv4 already have this. I think our server just > > sets this to a constant, and our client doesn't use it. > > I know that NFSv3 and NFSv4 send nanosecond-resolution > timestamps over the wire. That's not the problemm. They actually have a time_delta per-filesystem attribute. From RFC3530: time_delta 51 nfstime4 READ Smallest useful server time granularity. I only took a brief look, but it seems that our client doesn't use this (since there was no _PC_TIMESTAMP_RESOLUTION pathconf...). And our server, IIUC, has a hard-coded constant for this (since there was no _PC_TIMESTAMP_RESOLUTION VOP_PATHCONF...). > What is needed is a VOP_PATHCONF(_PC_TIMESTAMP_RESOLUTION) > operation for NFS that returns the actual timestamp resolution > for the underlying file system. Yes; the protocol has it already. Sorry I wasn't clear earlier. I did a quick search for solaris/kernel/nfs CRs that mention time_delta, and found none. Nico --