RE: Re: EAR/WAR Deployment Symbolic link problems

Joe,

As I understand it, a hard link is a directory entry that points to 
another directory. A symbolic link is a file containing the path to 
the other directory. Create hard links by not specifying -s on 
an ln or *HARD on crtlnk. You can use the -H option to prevent copies 
from chasing your symbolic links something like:

cp -RH dir1 dir2

or QSH CMD('cp -RH dir1 dir2')

David Morris


>>> joepluta@xxxxxxxxxxxxxxxxx 7/8/2003 6:04:56 PM >>>
> From: David Morris
>
> In your P.S. I read that you are having problems with JAR and ZIP
> files.
> Since I have used symbolic links quite a bit in the past and haven't
> run
> into these problems, I thought I would check it out. You are right
that
>
> there appears to be some issues but it appears that a hard link did
> work
> in my tests. I also found that a symbolic link to a directory always
> works
> (which is what I must have always done or something broke). I did
> find an example in IBM's 4.5 manual saying you should create
symbolic
> links to the JDK jars you add to the ext directory, implying that it
> worked
> at one point or that the ext directory/JDK jars are somehow
different.

When you say a hard link "works", what do you mean?

For example, I create a directory (dir1) and in it I place a symbolic
link
to another directory - (symdir1 which is a link to subdir1).  I then
copy
the first directory to another name (dir1 to dir2).  What happens is
that
dir2 has a directory called symdir1, which is NOT a symbolic link, but
is
instead a real directory, and it contains real copies of all the
contents of
the original subdir1.

And this makes sense, to a degree.  There should be an option for a
copy to
not dereference symbolic links, but I am no link expert, so maybe I
just
missed that one.

However, this can get VERY ugly.  In my setup, I have a folder which
contains a link to its parent.  By definition, this folder can now
never be
copied because copying the folder will dereference the link, which will
copy
the contents of the parent which will copy the original folder which
will
dereference the link... and so on.

Unfortunately, ZIP and JAR both dereference links, and so this sort of
recursive link causes the same problem - an endless loop until
something
blows up.

Since my workaround for the hardcoded J2EE file structure requires two
links
to the same folder, one containing the other, you can probably see that
I
have a recursive setup.  That means I cannot save that folder.

Which is no big deal; it's just a couple of links which can be created
at
installation time, except that another weakness in the J2EE deployment
model
is that there is no provision for post-installation scripts.

Oh well, someday it may grow up to be a real industrial strength
deployment
model, but until then I will have to work around it.

Joe