Top | Previous | Next


Limitations

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.



Top | Previous | Next