app works when copied with tar, not with rsync

[Brian Poole]

On Dec 29, 2007 4:33 PM, Matt McCutchen <matt at mattmccutchen.net> wrote:
> On Thu, 2007-12-27 at 17:52 -0500, Brian Poole wrote:
> > I'm experiencing a most unusual problem.. I am copying a directory
> > from one server to another (both Solaris 10/SPARC). No applications
> > are using the directory in question on either side while the copy is
> > in progress. After the copy successfully completes (no errors or
> > warnings), my user brings up the application (mix of binaries, java
> > files, and Apache Tomcat servlets) contained in this directory on the
> > new server. Or at least, they try to..
> >
> > If I use rsync to perform this copy (tested with 2.5.5 and 3.0.0pre7),
> > the application logs an unusual Java error (reproduced near the
> > bottom) and dies. Surely an application issue, right?
>
> I can think of one potential difference between rsync and tar results
> that you haven't mentioned: the order of entries within each directory.
> You can see the order with "ls -U".  Some filesystems, such as ext2,
> tend to leave directory entries in the order they were originally
> created.  Others, such as reiserfs, seem to automatically sort the
> entries in such a way that two directories containing the same names
> always read in the same order.  On a filesystem of the first kind, tar
> will tend to give you a destination with the same entry order as the
> source, while rsync sorts the entries to some extent.
>
> It is conceivable that your application needs the directory entries to
> be in a certain order to work correctly.  (Of course, such a dependency
> constitutes a bug.)  The way I can see this happening for a Java
> application is if it uses a classpath entry of the form dir/* (to match
> any number of jars in the directory) and multiple jars provide
> identically named classes.  In my tests with Sun's Java 1.6.0_02 on
> Linux, the application gets the class from the jar that comes first in
> the directory; if rsync reorders the directory, the application may get
> the wrong class.  If this is indeed the problem, there isn't much you
> can do except report the bug and use tar in the meantime.

The Solaris UFS filesystem's readdir is of the first variety. it
returns files in the order of creation. There are definite differences
between the rsync & the tar/original copy in terms of file order. By
the way, the (rough) Solaris equivalent of GNU's "ls -U" is "ls -f".

I am working with the application team (and then hopefully the vendor)
to see if we can find an errant class path that would be hitting this
difference. Thanks again for the great insight Matt.

Brian