Can't follow link on Unix

Hi all,

We have problem with deployments to Solaris after an upgrade to OD 5.6 SP1 + patch 1520 (src=Windows).

First we have created a test structure as follow on the receiver side

testroot
|-----------mydir
|-----------mydir-app -> mydir

When trying to deploy a file to mydir-app (filelist deploy) which are supposed to land in mydir we get the following message on the receiver side

(2) id=0 server: Abs Path = /stc/JRun4/servers/stag.secure.skandia.de Relative Path = test/mydir-app/joachim.txt
(2) id=0 server: Path = /stc/JRun4/servers/stag.secure.skandia.de/test
(2) id=0 server: Path = /stc/JRun4/servers/stag.secure.skandia.de/test/mydir-app
(2) id=0 server: ERROR: Link encountered in /stc/JRun4/servers/stag.secure.skandia.de/test/mydir-app/joachim.txt
(2) id=0 server: ERROR: Cannot follow the link

To see if it maybe is a problem with filelist deploy we also have tried to do an ordinary deploy (same source and target), what happens now is that

1. The file is deployed :-)
2 When examine what happened on the receiver side we can see the following
The link mydir-app is destroyed and has been replaced by an ordinary directory and of course the file is within that directory as well :-(((

Have anyone out here any idea of what may be the cause?

Thx all of you

Joachim

Opponent

Find more posts tagged with

Comments

Adam Stoller

This question really should have been posted in the OpenDeploy forum. (heh, you figured that out yourself while I was trying to respond to it ;-)

Not clear why you need the symlink of the directory - if you can figure out a resolution for your situation that doesn't involve a symlink you'll probably be happier in the long run. If the files are supposed to be in mydir - why deploy them to myapp/mydir? If you need to deploy them to myapp/mydir, perhaps you could make mydir a symlink to myapp/mydirr instead of the other way around?

There's a followLinks attribute for the sourceTransferRules element in OD 6.0.2 (there used to be a similar attribute in other elements but the matrix for trying to determine the correct behavior in all situations was incredibly difficult and error prone and thus was removed sometime after 5.5.1)
If you want to report the oddity / difference of the behavior between different deployment styles - contact support.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

ml372

Hi,

at the moment we have the same problem and get the same ErrorMessage
(2) id=0 server: ERROR: Link encountered in ...
(2) id=0 server: ERROR: Cannot follow the link

I have set the property

...
allowTargetFollowLinks="yes"
/>
in the odbase.xml and odrcvr.xml stop and start the Receiver/ BaseServer.
Additionally i have set the transferrule in the deploy-config file followLinks=yes, but it doesnt work!!

I think its an bug, an will open a Support case. If anyone have an solution, i will be happy to know it.

kind regards

sample02.ZIP

skip11

Hi all,

We have problem with deployments to Solaris after an upgrade to OD 5.6 SP1 + patch 1520 (src=Windows).

First we have created a test structure as follow on the receiver side

testroot
|-----------mydir
|-----------mydir-app -> mydir

this is a soft link (ln -s) try a hard link: ln mydir mydir-app

regards,

Adam Stoller

this is a soft link (ln -s) try a hard link: ln mydir mydir-app

regards,

I believe that directories can only be soft-linked - where files can be either soft-linked or hard-linked.

Dealing with links in deployments has always been problematic - see [thread=6617]this thread[/thread] for some additional details.

blacke

I had the same problem today and troubleshot it until I think I have an understanding of how the sym links problem can be resolved. I know this is an old thread, but someone might need the info.

I'm using OD6.1 base and rcvr on two Sun boxes with Solaris 9.

There doesn't seem to be any problem with links above the targetFilesystem area as long as both parts of the link are allowed directories, so I don't think there is any configuration is required.

Otherwise, in the admin guide the solution specified works, but took some time to get right. This is it:

1) The reciever must have the listener properties set <listenerProperties ... allowTargetFollowLinks="yes"/>

2) The deployment config needs the filelist targetFollowLinks specifed <filelist ... targetFollowLinks="yes">. This is only possible with the 'New Source' source type (not the 'Legacy Source').

This is a sample that worked for me:


    <definition name="MYDEFINITIONNAME" >
        <source >
            <fileSystem name="" >
                <filelist area="/.iwmnt/default/main/Content/WebContent/STAGING" filePath="$filelist^" name=""
                      targetFollowLinks="yes" deleteAfterComplete="no" >
                    <pathSpecification >
                        <path name="." />
                    </pathSpecification>
                </filelist>
            </fileSystem>
        </source>
        <target useReplicationFarm="prod_weblogic" >
            <comparisonRules dateDifferent="yes" revert="no" ignoreAcls="yes" ignoreModes="no" ignoreUser="no" ignoreGroup="no" checksumCompare="no" />
            <transferRules doDeletes="yes" dontDo="no" preserveAcls="no" followLinks="no" svrTryCount="" svrTryInterval=""
                       svrTryDisableOverwrite="no" rmReadOnly="no" compression="no" compressionLevel="" applySourceFileTime="yes"
                       checksumVerify="no" byteIncremental="no" />
            <permissionRules amask="" omask="" directory="0775" file="0664" group="webmstr" user="webmstr" changeAccess="" setAccess="" />
            <targetFilesystem area="/nas/content/internet" />
            <replicationFarmLink >
                <internal name="prod_weblogic" />
            </replicationFarmLink>
        </target>
    </definition>

The transfer rules 'followLinks' is not needed. From what I gathered, it is used when a symlink is being created from the source machine to the target. With followLinks set to 'no', the file/directory the link points to will not be deployed. If set to 'yes', it will.