currently just using the simple file deployer service as is.
we will modify it to have userid/password authentication eventually
We don't want the pages to automatically deply to the production. We have a staging server for the purpose of testing/previewing BEFORE going to production.
For SFDS to function properly two things need to taken care of
1. The directory structure in the staging server, should match with the directory structure in the Live server
2. Secondly, the username and password that is provided in the services (windows services) for CPS (Log on as...) should have administrative rights on both the staging and the Live server.
Please ensure this.
Hope this helps
Sudharshan.S , yes the file and directory structure is identical and the contribute publishing service has administrator access.
If you're on running CPS on a Windows server with .NET Framework 2.0 and are using .NET to handle your dvlp->staging->production, you might want to look at your event log. We were experiencing a similar problem and it had to do with our webdav interactive user account not having a profile (see MS Article 913384). We obtained a hotfix from MS and it corrected the problem. The interesting (or not so interesting) thing is that the problem appeared after a regular MS security update.
we are not using .Net
Strictly using ColdFusion MX 7 and CPS 1.1 with IIS 5 on Windows 2000
I have exactly the same problem - see my topic
quote:. I'm running CPS 1.1. on a Windows 2003 Server with IIS 6 and .NET. All the permissions appear to be correct, but deployment of dependent files (PDFs and images) is inconsistent, and I can't see any pattern yet. I'm having to use Dreamweaver to synchronize folders after deploying the updates, which is far from ideal!
Simple Filedeployer and supporting files
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.
Quarry Integrated Communications Inc.
Waterloo, ON, Canada
That is interesting. Something that may be related to the problem in a Windows environment is the length of "changes" xml file path name. I noticed that when I deployed some changes (using an unmodified Simple File Deployer) the entries did not get removed from the "changes" folder, even though the file had been deployed. So I went to the changes folder in Windows Explorer and tried to delete the relevant xml file: the delete command wasn't available! I looked at the complete file path, it was 260 characters long. It looks as if Windows can't handle a file name that's longer than the magic 255. I was able to delete the xml file using the DOS command prompt window.
I haven't definitively checked whether this applies to dependent files, but I wouldn't be surprised if it does.
Another couple of complications with dependent files are:
1. The CPS will only pick up on files that have been added using Contribute. Any dependent files that existed in the page before Contribute edited the file, or that are added with Dreamweaver, don't get added to the list of dependent files.
2. Dependent files don't get removed from the list of dependent files when their links are removed from a page.
3. I haven't found a way of getting into the xml-Dependencies file to edit it: access denied (though stopping the CPS service might free it).
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
Any real solutions, aside from my having to synchronize every time an employee
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:
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:
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.