WARNING - deployment receiver is DANGEROUS

[ftoth]

Hi again,

Not one response from Alfresco on my previous post, eh?

I know a little bit more about this now. It's completely repeatable, and has
to do with, apparently, only the initial deploy to a "fresh" deployment receiver.

Be very cautious when you define the value for "root" in the targetData
property. It should be a completely empty directory, except for a
single sub-directory named "ROOT". If you have any files in either the
target directory or in the ROOT subdirectory that are not managed by
alfresco, the deployment receiver will remove them for you on the first
deployment.

It seems that the first deployment is the key. The deployment receiver must
establish some sort of base-line from that first run. Afterwards, you can
add non-Alfresco stuff and it won't be deleted.

At least as far as I know. I wish I could be sure of this last point.

What happened to me:

My web site's root was "/usr/www/ROOT". As I mentioned before, I am
using Alfresco for only a small subset of the site. So /usr/www was
filled with lots of stuff, as was, of course, /usr/www/ROOT.

I set "target" to "/usr/www".

I created a single folder with 2 files in Alfresco and did a deploy.

The files deployed nicely. And the deployment receiver deleted
everything in /usr/www and in /usr/www/ROOT except for the newly
deployed files.

I'd call this a very dangerous bug!

Thanks,

Fred

[ftoth]

Hi Scott,

I'm still around!

However, we're still running 2.1 community, so I'm not sure if my solution is still relevant.

We ended up taking advantage of the "post deploy" feature of the deployer. We point
the deployment receiver to a safe directory that it's free to manage. We then have
a post deploy script that runs on every deploy. Our script is free to do whatever we
need, including ignoring alfresco delete commands if necessary.

Hope that helps.

Fred

[scottf]

Thanks very much for the replies guys.

mrogers - yes I am using a 3.1 FSR, but the "errorOnOverwrite" was set to the default false. I'll change it to true and re-test.

Fred - thanks for the information. That's definitely a good option if I don't get the out-of-the-box functionality I need.

I'll post back here after I run some tests to let others know.

Thanks again,
Scott.

[scottf]

Ok,
Some interesting behaviour.

I've retested after setting errorOnOverWrite to true and restarting my FSR.

Within Alfresco Explorer I then created a webapp sub-folder I know already exists in my deployment location and I added a single file.

I then submitted my changes and deployed to that FSR. With errorOnOverWrite set to true an error is thrown and the deployment fails. I think this is expected.

09:59:26,385 WARN  [org.alfresco.deployment.impl.server.DeploymentReceiverServiceImpl] writing to pre-existing directory, path:C:\Toolkit\Stores\WebContent\StoreOne\javascript
09:59:26,385 ERROR [org.alfresco.deployment.impl.server.DeploymentReceiverTransportImpl] error in mkdir ticket:b4bd1304-228f-4c9e-a9b9-7ece18fa9f2e, path:/javascript, guid:7f16cbc7-6f8f-4372-9f98-c81d19562074
org.alfresco.deployment.impl.DeploymentException: directory already exists, path:C:\Toolkit\Stores\WebContent\StoreOne\javascript‍‍‍

In this case the new file doesn't get pushed to the FSR.

When I run the FSR with errorOnOverWrite set to false the following happens:
Within Alfresco Explorer I created another webapp sub-folder I know already exists in my deployment location and I added a single file.

When I then browsed the file system the folder was there but all it now contains is the single file I added through the client, all my non-alfresco files and folders that were stored in the same folder on the file system have now been deleted.

In the deployment.log file it does mention that it is writing to a pre-existing directory, but it still goes ahead and deletes that folder's contents anyway….seems odd:

    09:30:28,167 WARN  [org.alfresco.deployment.impl.server.DeploymentReceiverServiceImpl] writing to pre-existing directory, path:C:\Toolkit\Stores\WebContent\StoreOne\css
‍‍‍

To re-cap I am using Alfresco 3.1 on windows XP, derby DB (for evaluating and testing), and a 3.1 FSR also on windows XP.

Is this the standard behavior for 3.1? or is this a bug?

What I need is for the FSR the be able to copy content into an existing folder, but not delete the non-alfresco content in that folder. Is this possible?

I need to get this working as the plan is to use Alfresco for managing the static content of a very large website.

mrogers - any ideas?

[mrogers]

I've just checked the code and it looks like a bug    Alfresco taking over the directory "C:\Toolkit\Stores\WebContent\StoreOne\css" has been too agressive.

Could you raise your scenario in Jira please?

As an immediate work around deploy from alfresco first and then copy in your extra content.

Or if you want to patch your source code replace the DeploymentReceiverServiceImpl.java lines #276-281 with if(!f.exists()) { f.mkdir(); }

[scottf]

wow…that is bad news, thanks for investigating.

I added an issue in JIRA (my first one, so it might be incorrect), but I could only mark it againts labs, not ENT 3.1.

Maybe you could move it? https://issues.alfresco.com/jira/browse/ALFCOM-2784

I am currently not working from SVN, so the code change is not really an option at the moment.

[mrogers]

ALFCOM-2784 is now fixed on HEAD.