File Names:
ChronoSync, being a truly native Mac OS X application, has no problem dealing
with long file names. Our definition of long file names is files whose name
exceeds 31 characters in length. However, support for long file names may not
be present when connected to a variety of servers.
The most significant example of this is when connected to a computer running
Mac OS 9 (or earlier). While Mac OS 9 supports the HFS+ volume format (necessary
for long filename support), much of the software running on Mac OS 9 is not
capable of recognizing these long names. The file sharing services built into
Mac OS 9 likewise won't recognize these long names. Thus it is possible that,
when synchronizing with a Mac OS 9 (or earlier) based machine, you will get
"Filename too long" errors. There's really nothing that can be done about this
except to limit your file names to less than 32 characters.
The same limitation may arise when communicating with other file servers that
implement a file sharing protocol known as AFP (commonly, and incorrectly, referred
to as "AppleTalk"). This would include, but not be limited to, AppleShare IP
and Netatalk servers. Some AFP servers, such as Mac OS X Server, however, have
no such problems.
Path Names: A path name is a string of text that lists each folder in
a folder hierarchy. Each component of the path is separated by a "/" character.
For example, the path to your "Documents" folder, assuming your name is "Joe",
would be "/Users/Joe/Documents". ChronoSync has a limitation of how deep a folder
hierarchy can go - a total path name cannot exceed 1024 characters. It would
require an extremely deep folder hierarchy to exceed this limit, but the limit
exists nonetheless. The limit is imposed by the ANSI code libraries upon which
we are based. In fact, the underlying Mac OS X file management facilities that
we use have the same limitations, so there is really very little we can do about
this. Fortunately, for the overwhelming majority of users, this is not a problem.
Modification Dates: ChronoSync uses a file's modification date to determine
if it requires synchronization. When file A has been modified more recently
than file B, it is tagged for synchronization. This mechanism works very well
as long as the dates are accurate. Fortunately, they usually are accurate, but
when dealing with file servers, the accuracy can be compromised.
The fundamental problem when dealing with file servers (and remember, a laptop
communicating with a desktop is communicating with a file server) is that the
two computers have independent clocks and thus time-stamp files with their own
local time. For example, if computer X's internal clock is five seconds faster
than computer Y's, what happens when a modified file is moved from computer
X to computer Y? If no special handling is performed, computer Y will see a
file that was modified five seconds after it actually was. This can wreak havoc
on file synchronization programs such as ChronoSync.
Luckily, most file servers account for differences in clock settings and even
time zones. When connecting to a file server, two computers 'synchronize their
watches' so-to-speak, so that differences in time settings and/or time zones
are accounted for. However, we've experienced times when this synchronization
isn't exactly perfect. In such situations, the same files may be synchronized
over and over again, even though they haven't been modified at all. Using the
Analyze Tab Panel to inspect these files reveals a modification date that is
off by one second. This is your clue that the two computers may not be synchronizing
their clocks accurately.
Luckily, ChronoSync offers a setting called "Allowed time difference:". This
indicates the number of seconds difference that must exist between two files
before they are truly considered different. The "Allowed time difference:" setting
may be modified in the Options drawer of the Analyze Tab Panel. In the above
example, specifying an allowed time difference of 1 second would solve the problem.
In some extreme circumstances, two computers cannot agree on things like their
time zone or whether or not daylight savings time is in effect. In such cases,
two synchronized files may show time differences of an hour or more, even though
they were just synchronized. In these cases, the only solution is to specify
a very large "Allowed time difference:" setting. If the times are off by exactly
an hour, 3600 seconds should be specified (the "Allowed time difference:" setting
may be as large as 99,999 seconds). Tip: In these cases, synchronizing at application
launch, and launching at login are very useful since there would usually be
no question about whether or not a file was modified within the previous hour.
Busy Files: Files that are 'busy' are simply those that are in use by
another application when synchronization occurs. ChronoSync is designed to wait
briefly when these files are encountered on the assumption that they won't be
busy for long. If a file shows no sign of leaving the busy state, ChronoSync
skips it and posts an entry to it's log.
This behavior is desired since copying a file that is in use by another application
may copy data that is in an interim state and thus be unusable by that application.
However, because of this behavior, ChronoSync should not be used to synchronize
or backup targets that contain very dynamic data, i.e. files that may be constantly
changing while a synchronization occurs. If files are constantly in use, a complete,
successful synchronization would rarely occur.
If synchronization absolutely must occur on this type of data, it is best to
use the scheduler to invoke the synchronization at a time of day where where
activity is less likely, such as the middle of the night or during lunch hour.