Bug 5506 - support utime differences at runtime, not configure/build time
Summary: support utime differences at runtime, not configure/build time
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.3
Hardware: All Linux
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL: http://thread.gmane.org/gmane.network...
Depends on:
Reported: 2008-05-31 01:35 UTC by Mike Frysinger
Modified: 2010-08-26 17:32 UTC (History)
0 users

See Also:

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

the rsync code currently does things like:
	<do utimes stuff>
#elif defined HAVE_UTIME
	<do utime stuff>

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:
	<do utimes stuff and return if successful>
	<do utime stuff and return if successful>
	<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.