autoconf-patches
[Top][All Lists]
Advanced

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

21doc-cp-r-portability.diff


From: Derek Robert Price
Subject: 21doc-cp-r-portability.diff
Date: Wed, 10 Nov 2004 09:22:57 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Just a quick suggestion to patch the autoconf docs to mention a portability
limitation of `cp -r' that a member of the CVS team recently discovered.
Also includes a minor reordering.  I shifted one paragraph up since notes on
the limitations of `cp -f' were included in the middle of three or four
paragraphs on `cp -p' and I thought it made more sense to group them
together.
                                                                              

ChangeLog:
                                                                              

2004-11-09  Derek R. Price  <address@hidden>
                                                                              

        * doc/autoconf.texi (Limitations of Usual Tools): Note `cp -r'
        limitations.  Reorder paragraphs for clarity.

Cheers,

Derek

-- 
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.837
diff -u -p -r1.837 autoconf.texi
--- doc/autoconf.texi   11 Oct 2004 21:42:06 -0000      1.837
+++ doc/autoconf.texi   9 Nov 2004 16:46:18 -0000
@@ -11223,20 +11223,11 @@ newline encoding.
 @item @command{cp}
 @c ---------------
 @prindex @command{cp}
address@hidden timestamp resolution
-Traditionally, file timestamps had 1-second resolution, and @samp{cp
--p} copied the timestamps exactly.  However, many modern filesystems
-have timestamps with 1-nanosecond resolution.  Unfortunately, @samp{cp
--p} implementations truncate timestamps when copying files, so this
-can result in the destination file appearing to be older than the
-source.  The exact amount of truncation depends on the resolution of
-the system calls that @command{cp} uses; traditionally this was
address@hidden, which has 1-second resolution, but some newer
address@hidden implementations use @code{utimes}, which has
-1-microsecond resolution.  These newer implementations include GNU
-coreutils 5.0.91 or later, and Solaris 8 (sparc) patch 109933-02 or
-later.  Unfortunately as of September 2003 there is still no system
-call to set time stamps to the full nanosecond resolution.
+BSDI BSD/OS 4.2, at the least, has a problem with a trailing @samp{/} on the
+destination of a @samp{cp -r} command when said destination does not exist.
+For example, if @file{/tmp/newdir} does not exist, use
address@hidden -r source /tmp/newdir} rather than @samp{cp -r source 
/tmp/newdir/}
+to assure portability.
 
 @c This is thanks to Ian.
 SunOS @command{cp} does not support @option{-f}, although its
@@ -11253,6 +11244,21 @@ newer systems, @code{rename}).
 @c Ian said: ``I don't think -p or -r are portable''!!! How can you live
 @c without -r???
 
address@hidden timestamp resolution
+Traditionally, file timestamps had 1-second resolution, and @samp{cp
+-p} copied the timestamps exactly.  However, many modern filesystems
+have timestamps with 1-nanosecond resolution.  Unfortunately, @samp{cp
+-p} implementations truncate timestamps when copying files, so this
+can result in the destination file appearing to be older than the
+source.  The exact amount of truncation depends on the resolution of
+the system calls that @command{cp} uses; traditionally this was
address@hidden, which has 1-second resolution, but some newer
address@hidden implementations use @code{utimes}, which has
+1-microsecond resolution.  These newer implementations include GNU
+coreutils 5.0.91 or later, and Solaris 8 (sparc) patch 109933-02 or
+later.  Unfortunately as of September 2003 there is still no system
+call to set time stamps to the full nanosecond resolution.
+
 Bob Proulx notes that @samp{cp -p} always @emph{tries} to copy
 ownerships.  But whether it actually does copy ownerships or not is a
 system dependent policy decision implemented by the kernel.  If the

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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