Bug 5506 - support utime differences at runtime, not configure/build time
support utime differences at runtime, not configure/build time
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.3
All Linux
: P3 enhancement
: ---
Assigned To: Wayne Davison
Rsync QA Contact
http://thread.gmane.org/gmane.network...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-31 01:35 UTC by Mike Frysinger
Modified: 2010-08-26 17:32 UTC (History)
0 users

See Also:


Attachments
Patch to allow utimes or utime to be called (3.59 KB, patch)
2008-05-31 10:50 UTC, Wayne Davison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2008-05-31 01:35:52 UTC
http://bugs.gentoo.org/218577

the rsync code currently does things like:
#ifdef HAVE_UTIMES
	<do utimes stuff>
#elif defined HAVE_UTIME
	<do utime stuff>
#else
	fail!
#endif

the problem here is when rsync detects the utimes function.  the older utime 
code is ifdef-ed away so it isnt available at runtime.  that means rsync will 
only be runtime usable on newer systems.  if you take a recent glibc and 
compile it against recent kernel headers, you get a C library that supports 
both utimes and utime, and will run fine regardless of the kernel.  if it 
supports utimes(), glibc will return the expected values.  if it doesnt, 
glibc will return ENOSYS.

what i'm proposing is decoupling of the #if logic so that it isnt an if;else:
#ifdef HAVE_UTIMES
	<do utimes stuff and return if successful>
#endif
#ifdef HAVE_UTIME
	<do utime stuff and return if successful>
#endif
	<return failure>
Comment 1 Wayne Davison 2008-05-31 10:50:35 UTC
Created attachment 3324 [details]
Patch to allow utimes or utime to be called

This patch moves the time-calls into syscall.c (where they belong), and then extends the login in set_modtime() to allow a fallback of using do_utimes() to using do_times() if it gets an ENOSYS error on a normal file or directory.  See what you think of this logic.
Comment 2 Wayne Davison 2008-05-31 10:51:40 UTC
I'm considering this for inclusion in 3.0.4 (as it is too late to get into 3.0.3).
Comment 3 Mike Frysinger 2008-05-31 12:06:50 UTC
that seems to accomplish what i proposed nicely ... i dont actually have a system to test against though, but i'll see if i can get someone to test it
Comment 4 Mike Frysinger 2008-06-01 16:49:45 UTC
i got a user who is affected by this and they said the patch in question worked for them when applied to rsync-3.0.2
Comment 5 Wayne Davison 2010-08-26 17:32:21 UTC
I'm checking in a change for this.