bug-gnulib
[Top][All Lists]
Advanced

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

Re: touch gets stuck for named pipes


From: Pádraig Brady
Subject: Re: touch gets stuck for named pipes
Date: Thu, 9 Apr 2009 09:48:15 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20071008)

Jim Meyering wrote:
> ipif wrote:
>> I'm using coreutils-7.2 on an embedded sparc V8 with linux-2.6.21 and
>> uclibc-0.9.30.
>> The problem is, that in utime.c(73) it is tried to read a char from the file
>> and to write it back. As the fifo is empty touch gets stuck waiting for
>> input.
>> Because I'm crosscompiling HAVE_WORKING_UTIMES is always unset. Exporting
>> gl_cv_func_working_utimes solved this for me,
> 
> Thanks for the report.
> It sounds like you're saying that when cross-compiling
> you had to set gl_cv_func_working_utimes to avoid this problem.
> That is normal.  There are several configure-time tests that
> must be skipped (and for which we choose a pessimistic default)
> when cross-compiling.  Hence, you, the person who knows about
> the target, must identify those variables and specify more accurate
> settings for your target system.
> 
>> but no the issue at all.
> 
> I'm not sure I understand this final phrase.

I had a quick look at that function in utime.c and
it seems a bit over-engineered. I see that it tries
to emulate utime("file", NULL); with read(1);write(1);ftruncate();
I.E. to handle systems with no utime() or utimes() at all.
How likely is that though, and is ftruncate() more likely
to be missing than utime()? Also we seem to link against
utime() anyway for the case where times are specified.

So would this simplification be appropriate, which just handles systems
where utime("file", &ut); is OK while utime("file", NULL); is not?

cheers,
Pádraig.
diff --git a/lib/utime.c b/lib/utime.c
index 9ddb8b8..1f0d151 100644
--- a/lib/utime.c
+++ b/lib/utime.c
@@ -19,23 +19,14 @@
 #include <config.h>
 #undef utime
 
-#include <sys/types.h>
-
 #ifdef HAVE_UTIME_H
 # include <utime.h>
 #endif
 
 #if !HAVE_UTIMES_NULL
-# include <sys/stat.h>
-# include <fcntl.h>
+# include <time.h>
 #endif
 
-#include <unistd.h>
-#include <errno.h>
-
-#include "full-write.h"
-#include "safe-read.h"
-
 /* Some systems (even some that do have <utime.h>) don't declare this
    structure anywhere.  */
 #ifndef HAVE_STRUCT_UTIMBUF
@@ -46,11 +37,6 @@ struct utimbuf
 };
 #endif
 
-/* The results of open() in this file are not used with fchdir,
-   therefore save some unnecessary work in fchdir.c.  */
-#undef open
-#undef close
-
 /* Emulate utime (file, NULL) for systems (like 4.3BSD) that do not
    interpret it to set the access and modification times of FILE to
    the current time.  Return 0 if successful, -1 if not. */
@@ -61,40 +47,9 @@ utime_null (const char *file)
 #if HAVE_UTIMES_NULL
   return utimes (file, 0);
 #else
-  int fd;
-  char c;
-  int status = 0;
-  struct stat st;
-  int saved_errno = 0;
-
-  fd = open (file, O_RDWR);
-  if (fd < 0
-      || fstat (fd, &st) < 0
-      || safe_read (fd, &c, sizeof c) == SAFE_READ_ERROR
-      || lseek (fd, (off_t) 0, SEEK_SET) < 0
-      || full_write (fd, &c, sizeof c) != sizeof c
-      /* Maybe do this -- it's necessary on SunOS 4.1.3 with some combination
-        of patches, but that system doesn't use this code: it has utimes.
-        || fsync (fd) < 0
-      */
-      || (st.st_size == 0 && ftruncate (fd, st.st_size) < 0))
-    {
-      saved_errno = errno;
-      status = -1;
-    }
-
-  if (0 <= fd)
-    {
-      if (close (fd) < 0)
-       status = -1;
-
-      /* If there was a prior failure, use the saved errno value.
-        But if the only failure was in the close, don't change errno.  */
-      if (saved_errno)
-       errno = saved_errno;
-    }
-
-  return status;
+  struct utimbuf ut;
+  ut.actime = ut.modtime = time (0);
+  return utime (file, &ut);
 #endif
 }
 

reply via email to

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