Re: -times question

Greg Troxel <[email protected]>
Newsgroups gmane.network.unison.general
Message-ID <[email protected]>
"'R. Lammers' via unison-users" <[email protected]> writes:

> I am a new user of unison on OS X.  I use "-time=true" to get the file 
> times consistent between machines, but the directory times are not 
> consistent.  In searching for a solution, I see this has been discussed on 
> various forums ~5-6 years ago and not possible back then.  Has a solution 
> been created or is one planned to be implemented?

"Planned to be implemented" is in general overly optimistic about unison
features because there are no resources available to be planned.  There
is an open issue:

  https://urldefense.com/v3/__https://github.com/bcpierce00/unison/issues/172__;!!IBzWLUs!VHYEU2vl2Q4aLS-L3J9AM5ur6mYILNfJWu8XKmp7QDflM5fCd0fMz0r_O7CKCQiM1Su8TkvUv8NH024mJg$ 

which is marked "wontfix", as a clue that nobody who is working on
unison is likely to implement this feature.

I suspect a basic issue is that some operations update the mtime of the
directory to present (file creation, removal, rename), and thus
"synchronizing times" has to separate "the time I want" from "the time
that happened because some other sync happened".

rsync is one way, and it can do the create/delete/rename on the
destination and then set the mtime at the end.

You are certainly welcome to read the code and experiment.  It might be
that a

  read dir mtime
  do operation
  set dir mtime

wrapper around each operation done by unison would avoid setting the
mtime inadvertently, and then letting directory mtimes be synced might
work ok.  But it might turn out to be much harder than that.


You might also explain why you care about directory mtimes being the
same.  (I'm not even syncing times, even though I should get around to
converting to that and seeing if it's ok for my use.)


-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.