                         OUTSTANDING UNISON BUGS
                         =======================

SHOWSTOPPERS
============

Mac OSX, Windows XP:
  - Unison does not understand extended attributes (OSX) or alternate data
    streams (XP) and will not synchronize them properly.

Linux, Solaris:
  - None known.

---------------------------------------------------------------------------
SERIOUS
=======

[June 2006, Jim]
  By the way, there is a bug if you are doing a merge and
  are propagating times, the times of the merged file end
  up different so you have to sync again.  I guess this
  might be a feature, I don't know which way to propagate
  the times...
  ==> Best to make them both equal to the time of merging


[July 2002, Findler]
  I get this message from unison:
    Fatal error: Internal error: New archives are not identical.
    Retaining original archives.  Please run Unison again to bring them
     up to date.
    If you get this message again, please notify unison-help@cis.upenn.edu.
  and I think that I know what's going wrong. Unison is somehow using a
  key consisting of the result of `hostname' (and maybe other stuff) to
  uniquely identify an archive. I have two macos x machine and I use both
  of them to sync to a third (solaris) place. The problem seems to be
  that unison can't tell the difference between two macos x machines,
  since the default setup under macos x always gives the hostname
  "localhost".
  --
  So, I wonder if there is some other way to distinguish the two
  hostnames. Things that come to mind: ip addresses (but that can be bad
  if the machine moves around), ethernet addresses (but my laptop has two
  of them -- still better than ip addresses, I think) or perhaps some
  macos-specific mechanism for getting the macos name of the computer.
  --
  For now, I've just changed the result of `hostname' on one of my
  machines, but I just made up something that no DNS server agrees with,
  so that might cause me trouble down the line, I'd bet.
  ===> We should use some more information to make sure the archive names are
       unique enough.  But what, exactly?

[APril 2002, Jason Eisner] Recently I found an aliasing problem that may
  endanger Unison's semantics.
  --
  The problem is with the "follow" directive, which is documented like
  this: "Including the preference -follow <pathspec> causes Unison to
  treat symbolic links matching <pathspec> as 'invisible' and behave as
  if the thing pointed to by the link had appeared literally at this
  place in the replica."
  --
  If one of these invisible (elsewhere called "transparent") symlinks
  points outside the replica, all is well and good.  But if it points to
  something in the replica, then Unison now has two names for the same
  file.  It doesn't currently detect the aliasing.  As a result, it keeps
  separate information for the two names in the archive files.
  [A long example is in a mailmessage in BCP's files]

starting Unison on two non-existent local directories leads to an
  assertion failure in path.ml

---------------------------------------------------------------------------
MINOR
=====

Sascha Kuzins  [July 2002]
  The server crashes everytime the client is finished.
      "Fatal Error: Error in waiting on port: "
          "The network name is not available anymore" (rough translation from
  German)
  I use Unison on two XP Professional machines, German versions, with the
  simple tcp connection.

BCP  [May 2002]
  The "rescan paths that failed previous sync" function misses some files.
  E.g., if a directory has failed to transfer because the disk ran out of
  space and I hit 'f', it will come back with "Everything is up to date",
  even though doing a full re-sync will again recognize the directory as
  needing to be transferred.

Jason Eisner [April, 2002]
  The Merge feature does not appear to modify file times.  Thus, when
  times=true, using the Merge feature on
     changed ? changed    myfile
  turns it into
     props   ? props      myfile
  and to finish the sync, I have to decide which file time "wins."
  This differs from the behavior that I would expect and find more
  convenient: namely, if I perform the merge at 3pm, then it counts as a
  change to BOTH replicas of myfile and they should both end up with a
  time of 3pm.
  So I'd suggest that myfile in the local replica should have its
  modtime as well as its contents changed to that of
  #unisonmerged-myfile (the temporary file produced by the Merge
  program).  Then this modtime and contents should be propagated to the
  remote myfile as usual, handling clock skew as for any other propagation.
  Other file properties should probably NOT be propagated.

Karl Moerder:
  The synchronization of modification times does not work on directories
  (WinNT folders) or on read-only files. I found this when I tried to
  synchronize mod times on an otherwise synchronized tree. It failed
  gracefully on these. The "[click..." message is a nice touch.
  ==> [Nothing we can do for read-only files; need to patch ocaml for
       directories...]

"After I synchronized two directories I created a new profile, which
  defaulted to the same directories.  I synchronized again (no changes,
  which was fine) but the Unison program did not save the directory names
  in the new profile.  Later attemts to use that new profile failed, of
  course, and further random clicking resulted in a message asking me to
  delete non-existent lock files.  I responded by exiting the program,
  manually deleting the .prf file, and starting over.  This is a minor
  bug, I suppose, the root cause of which is the failure to save the
  directory names in a new profile when they were copied unchanged from a
  previous profile and/or no files had changed in these directories --
  the type of bug that can only affect a new user, and so easy to
  overlook in testing."

The "Diff" window [under Windows] sometimes shows nothing.  Does this
  arise from a missing "Diff" program?  We should detect this case!

---------------------------------------------------------------------------
COSMETIC
========

Interactively adding an ignore pattern for src will not make
  src/RECENTNEWS immediately disappear (as it does not directly match
  the pattern)...
