Hi,

I've been having this problem for close to a year now with our in-house modified version of the stock "simple file deployer" service.

A recent development project has forced me to go into the codebase and rework it to add some custom functionality (auto-unpacking .zip file payload to simplify multi-file publishing) and while doing so, finally discovered the root of the problem for me - any maybe it will be the same for you.

Sorry for not sharing line numbers, but I've modified my codebase enough that they'll be irrelevant to you. In core.cfc, you'll find a function called getChangeRecord. Within that method, you'll find a cfinvoke call to the "getDirectoryList" function. Inside the directory argument for that method call, you'll see the string "-dependencies" which is used to make up the path to the dependency directory to check within. THAT was the crux of the issue for me. I'm running on a Linux server which is case-sensitive and the directory that CPS creates is called foo-Dependencies (note the capital D).... yet the CPS codebase is looking for a foo-dependencies directory with a lower-case 'd'.... hence, CF never finds the dependencies dir even though it is there, and the children of the published file never get copied using the file deployer.

Now, I know you mentioned you're in a Windows server environment, but perhaps this same issue is effecting you because of some difference like you using NTFS but the CPS devs at MacrAdobemedia were using FAT-32 partitions or something silly like that.

Anyhow - I hope this helps.. I literally cackled with glee today when I discovered this. And Abobe, if you're listening, please correct that for any future releases of CPS. Whether it fixes the issues on Windows servers or not, it is a legitimate resolution to the problem in any OS with a case-sensitive file system.

Justin Kominar
Interface Developer
Quarry Integrated Communications Inc.
Waterloo, ON, Canada

If we check-in or publish a page with PDF's and images, using Adobe Contribute or Dreamweaver, the go to the staging server successfully, but then when we deploy them from staging server to production server (using Contribute Publishing Service Simple File Deployer), it fails to deploy the PDF's and images, but does deploy the html pages.

 

If I use Dreamweaver to manually synchronize (force synchronization) to

 

put the associates PDF and images files to the staging server again, then the File Deployer works.

 

Any real solutions, aside from my having to synchronize every time an employee

 

puts a PDF on our website?

 

More details:

 

Simple File Deployer displays the files differently, depending on if they were synchronized or merely 'put' there with Dreamweaver/Contribute.

 

If merely put there, it looks like this, and fails to deploy:

___Parks/Meetings.html 

Staged version:Live version:
Published by name@...comname@..name@...com.com on 02/29/2012 08:59:38 AM

Associated files: Parks/documents/Agenda.pdf

 

If merely use Dreamweaver Synchronize, manually force, it looks like this (listing the PDF as a separate item), and deploys:

___Parks/documents/Agenda.pdf 

Staged version:Live version:
Published by name@...comname@..name@...com.com on on 02/29/2012 04:04:36 PM

___Parks/Meetings.html 

Staged version:Live version:
Published by name@..name@...com.com on 02/29/2012 03:15:07 PM

Associated files: Parks/documents/Agenda.pdf

 

A side note, the XML entries on the staging server look different in each case.  In the first unsuccessful case, the XML file for the PDF is only in a "..Dependencies" folder, whereas in the second successful case, there is also an XML file for the PDF in the regular changes/site folder.