-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ray,
On 6/3/15 9:44 AM, Ray Holme wrote: >> I'm curious as to why you are using hard links instead of >> symlinks. If you copy a new file over a hard link, you un-couple >> it from the rest of the series of hard links. If you do the same >> with symlinks, the result is probably more what you were >> expecting. There are other disadvantages with hard links >> including not really knowing that it's a link (symlinks are >> obvious) and they can't span across filesystems. > > Again correct, but for a while tomcat did not allow me to have > symbolic links (or I did not know about the way to overcome that > in the xml file). In any case, I solved the problem with a shell > script that makes sure the hard links are correct AFTER a complete > compilation set is done. Okay. I think you just have to set allowLinking="true". I don't understand the underlying reasons why Tomcat treats symlinks specially... I'm used to using *NIX utilities where the presence of a link (instead of a "real" file) isn't important unless you are specifically looking for a link (e.g. using readlink() instead of read() ). > The other problem (which may or may not be a problem - I have not > tried in a while) is making a WAR file. I cannot have symbolic > links then. Inside the WAR or having the WAR as a symlnk? You should be able to symlink WAR files, but you may have to have that allowLinking="true" (though not in META-INF/context.xml, since that's /inside/ the WAR, of course). > The target machine running the application just gets the WAR file > and NOT the directory containing the assorted jars. But perhaps I > should re-explore that one. I'm not sure what you mean, the "target machine". Perhaps this is a deployment issue and not a Tomcat one? > And by the way, you can edit the hard link file AND all versions > change. That's opening an existing file (inode) and changing the contents. Hard links are references to inodes, so this isn't surprising. > You can also "cat >file" and all hard links remain. This depends upon how the shell treats output redirection. One can truncate an existing file in-place, or one can delete the existing file and replace it. The former will give you the behavior you observe, while the latter will break your links (because you create a new inode). > It is ONLY when you move a file over one of the links that the > hard links are unlinked. Curious! cp will erase the existing file (well, the directory entry) and put the new one into its place, rather than re-writing the file. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVb1oQAAoJEBzwKT+lPKRYDxYQAMdrUiLfmQfGkJw23ExCd6Ns EqRL0YuCUvi1V1RXGlzDqjNHttgBaYR9XhcvKU+qp8JQF1KIMiBqWa4SR+70/Hij QaD+zFjbz6LWjDrB8Xq9HFXx7LItUe/mEs1fvyfOfzksZUoIdzjXCLG9jzVoEB0N cOExkSoT0rt/f7tjRfBXQBl+89j/tROukzHpMqtdYuUrWlTQIkeeRIh2C8TSBcGX YiiSQCVbr+5vOVCX7W2/gwOkBJffWYqKCZwno6RjszdVs0wmVtRV7ka+/SIpNp6T f2KYw+js0oFJzPoLVAlPCCHezNTKOdmlaK4GPDDYvc8/KK06zXNOh59c0+tMZ66i XCCJy5MYDK09u0eYMomdYOKINYizmlZ2I9rDRwUCukAMFrRd/4pFZXG5XgoPecFE oTltiMCntoKN9+HVarMP3jP8P3FFsaMuDp+maliaV4jByDbP18JX2A75+EyngXHx yUIwbpZxE4KSObxpYSebJutuibHmflMBQ6c1lQ3pTbW6kga2rOWs+tGU4EN1u6a6 eSiyyhHu2y0REqDLkXdXL285BUuiRgty6XQmx9rvbYnsLU3AImrDk7AKLqZmDuAL ueZprqSkOJW98lxQiXbE2G900hpKcSen5Jl6BOZrzcuI6Aw9LZ9YZ6kfYTlaCrUh BKfLKzZ9ZtYSUchRU0Cg =fuwD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
