It is just the performance issue. However, this issue is unacceptable
because of the number of files I am synching.. millions.. sending all of
these resource forks is just asking for trouble... using RsyncX I only
transfer a few thousand files each session but this error just transfers
resource forks 24 hours a day.. and this is insane.
I would gladly keep using RsyncX except it has a tendency to get Stuck
on Stupid and worry over a missing file or some such nonsence rather
than moving on.
I have found another project to fix rsync, but it still suffers from the
same problem but he/they have implemented some novel solutions to the
problem. Still the binary at onthenet is easy to install and seems to
work pretty well.
http://www.onthenet.com.au/~q/rsync/
Q. wrote to me..
I know in your notes you say this should only occur when the last
change time was more recent than the file's modification date, but
the net effect is that every resource copies every sync.
Is this what you are talking about when you are referencing
getattrlist? This seems more like spotlight data.. but perhaps I am
wrong.
Unfortunately yes. When you use the unix stat() function call it will
return an access time, a change time and a modification time. When you
modify the extended attributes of a file it will changes the change
time without touching the modification time. Unfortunately the unix
function call for setting these times doesn't allow you to set the
change time, and will instead set it to the current time, hence the
problem.
It appears that setattrlist() will allow the setting of a files change
time on a HFS+ volume which would eliminate this issue, however it's
syntax is somewhat complex, and I have not yet had a chance to work out
how to use it as my powerbook is currently in for repairs. So it might
be a little while before I have this problem fixed.
---
Appearantly the RsyncX people uses Apple specific Carbon library calls
to read and write data to accomplish not copying the resources..
David
J.D. Bakker wrote:
At 09:54 -0500 01-12-2005, David Powell wrote:
... ._resource forks being synced over and over despite the target
file itself not moving..
Is this Problem #4 mentioned in http://www.lartmaker.nl/rsync/ , or
something else ?
Missing fact...
I am attempting a link-destination based multiple backup that creates
hard links to files that are duplicates and only moves the changed
files.. This implementation of rsync is not noticing the existing
resource fork associated with the previous copy of the file so it
moves the resource fork again.
I hope this makes sense.
It would help to know if you're doing a local copy or a networked one.
Could you show us the full rsync command used ?
Are you experiencing data loss, or is this simply a performance issue ?
Regards,
JDB.
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
