It happens to mee, too.
I want my money back !
I'll return to previous version, or search other software if Adobe don't present a solution.
I've tested it in Mac Os X 10, XP and Vista....
Just wondering if there's a solution to this - I'm using the CS5 demo on a Macbook Pro and it's driving me crazy!
It was the same in CS4 and I was hoping for it to be improved in CS5 so I could persuade my boss to upgrade!
Hate to say it... but it seems to happen even more frequently in CS5. There's something quite clearly wrong, and this has been an issue for a long time.
What you need to do is to check how the Preferences have been set for your site Local/remote-- my observation is that many people have the site Preferences set incorrectly.
My discipline is to always work in Local environment then after finishing whatever is required -- test THEN synchronize with Remote.
If your Site Preferences are set to automatically interact with your Remote server You will get the behaviour that you describe.
I operate in remote mode most of the time. There are no actual problems with the server (I connect via WebDAV) nor with the site preferences - but 2/3 of the time, right clicking on any file in the remote view will yield the interacting with server dialog box - while the activity icon below indicates that that message is pure rubbish - the only thing *causing* interaction seems to be the click itself. In other words, it's busy interacting with the server to do the thing it can't do because it can't interact with the server while it's in use.
This has been an issue since at least CS3, and it's gotten worse, not better, with every version. Couple it with the many interface bugs (window toolbars getting orphaned from the containing window) under Mac OS X and it's a wonder they can sleep at night justifying new releases.
I forgot to mention that Live View Options is also where much of the automatic preferences are found -- make sure to check how your options are set.
I work with Local and Dynamic sites -- however all my development work is the Local environment -- for Dynamic sites I have my server installed locally for testing purposes.
Man, I was having the exactly same problem.
With no aparent reason, while clicking on a file in remote view, in most of
the times Dreamweaver tells me that it was interacting with server.
But for me, the actualization to CS5 just solve the problem. It's the same
hardware. I just uninstall CS4 and put CS5.
This bug don't appears in all systems, all the time. It's a question of
luck, hehe, so Adobe don't give the needed importance to it.
2010/6/22 Aaron_Knight <firstname.lastname@example.org>
I operate in remote mode most of the time. There are no actual problems
with the server (I connect via WebDAV) nor with the site preferences - but
2/3 of the time, right clicking on any file in the remote view will yield
the interacting with server dialog box - while the activity icon below
indicates that that message is pure rubbish - the only thing causing
interaction seems to be the click itself. In other words, it's busy
interacting with the server to do the thing it can't do because it can't
interact with the server while it's in use.
This has been an issue since at least CS3, and it's gotten worse, not
better, with every version. Couple it with the many interface bugs (window
toolbars getting orphaned from the containing window) under Mac OS X and
it's a wonder they can sleep at night justifying new releases.
Glad it's not just me on this :-)
(suffice to say this has stopped our company upgrading to CS5)
With me it seems to happen every couple of minutes when I have Checking In and Out enabled and if the server isn't totally reliable... it seems like Dreamweaver does a ton of stuff in the background to maintain the Check Out information, and if the server is slightly flaky it causes the time out. It'll then time out and try to continue the next background transfer.
This would be fine if these transfers stopped when I needed to upload/download files or do anything on the server, or if there was any way to cancel the File Activity... Clicking on the little globe underneath the file list shows the Transfer dialog timing out, yet clicking on the cancel button (if there is one - sometimes it's just a Hide button!) doesn't actually cancel it and nor does closing the dialog (even though it says it'll cancel it!!)
I've tried waiting for ages (over half an hour) to see if it'll sort itself out, but nothing - the only way to cancel the File Activity is to FORCE QUIT Dreamweaver - it won't even quit normally.
Anyway I find the problem totally goes away with Check In and Out turned off, which would be great if I didn't need to use it to stop us overwriting Client work and vice versa.
Surely it's not too much to expect this premium software to be able to handle the odd slow server??
Is this the same for others with the problem?
@Neil2010 writes: Is this the same for others with the problem?
Yes! And it's driving me crazy, too. I was using Dreamweaver 8. Unfortunately, once I upgraded my Mac OS to 10.5, and then 10.6, the copy-paste from Word docs stopped working properly, which was a big problem for me. But now I have upgraded to CS5 I have traded that one problem for a few worse ones, including this one (the other significant one is that Design View doesn't work properly for XHTML files). Adobe phone tech in India was no help. He accused me of improper coding. I showed him on the screen that my code passes W3C validation. He seemed clueless and just kept repeating that it must be something specific to my situation. I see from the many posts on the issues I'm having that it is definitely not. This is an expensive upgrade. It's all very depressing.
I have to wonder here how you have things set up in Dreeamweaver. I'm managing a lot of websites and, the only time I have any "interacting with server" message is when I am doing a "put" and I forget that it's not finished.
Here's how I am not using Dreamweaver:
I am not in a collaborative environment with several Dreamweaver artists are slogging away at website updates. It's just me. So, if you're in a collaborative environment, these settings may well not work.
In Site Definition, click on Advanced. Click Remote Info.
Your access will surely be FTP and you'll have your host all set, with login and password. You may or may not be set to use SFTP.
Below the Server Compatibility button you want "Maintain synchronization information" checked. There are two boxes below that. One is "Automatically upload files to server on save" and the last is "Check in/out" "Enable file check in and check out." These last two boxes are not checked on my Site Definitions.
I do believe that if you Check in/out, Dreamweaver will want a fairly constant connection to your server. This is designed for the collaborative environments that have a team of people working on websites and, in most cases like that, the server is not some remote server set up by a hosting provider, but a server the company owns outright (or is a colocation server).
A lot of the activity you may be seeing here with checking in and out is simply logging on to check the status of what is there to make sure your local folder stays in sync with the remote system.
When I'm working, I tend to have no connection whatsoever to my server until or unless I "put." Thus, I have short bursts of server interaction and hardly ever see any error of this type.
I do have file check in/check out enabled. I only work on my files on the local version and then upload them to remote when I am sure they are correct. There was a time when there was frequently someone else working on this site, though right now, I'm the only one, so I guess I could try disabling that feature as you suggest.
However, I am noticing that the problem is being caused when the file activity window stays open even after the file activity has been completed. Since it's in the background unless you click the log button, it took me a while to figure out that this is what is happening. Once I click the log button and manually close the window, the problem is solved. But I feel that is a glitch that Adobe should resolve, even if it is a problem that occurs only with check in/check out.
I'll try turning off check in/check out and see if it persists. But I really like having check in/check out as a safeguard.
I use Dreamweaver CS4 on Mac OS X 10.6.4 for a variety of sites. Only one site uses Check In/Out (to avoid editing "collisions" with a client who also uses Dreamweaver on his Mac).
6 hours ago, my client complained about annoying "interacting with server" messages. I did some quick testing, with a Check Out and Undo Check Out. I reported back to my client that I couldn't reproduce the problem.
WRONG. I just tried switching to another site, and Dreamweaver complained it's "Currently interacting with a server." This is especially annoying because all I wanted to do was stop using the client's server.
I was able to Quit Dreamweaver, after saying it was OK to terminate server activity. (I didn't capture the specific wording of that dialog.)
On relaunch, I was able to get Dreamweaver to switch to the other site.
That's good you were actually able to quit... normally here if I try to quit whilst Dreamweaver is trying to interact with the server, I get the dialog box you mention, press OK and the dialog disappears but Dreamweaver stays running.
I can leave it for ages but the only way to get out of it is a Force Quit!
Call: 02380 111 545
Semantic Limited is registered in England at 2 Venture Road, Southampton, Hampshire, SO16 7NP.
Company Number: 03820499. VAT Number: 711 7126 68.
I turned off Check In/Check Out a few days ago on the problematic site. That seems to have stopped the problem of the dialog boxes failing to close in the background and has sped up my workflow. But I think if Adobe is promoting Dreamweaver as having a built-in content management system that can accomodate sites that use Contribute or have more than one person working on it, they need to fix this. I only feel comfortable turning off Check In/Check Out because I am the only one working on the site now. But 2 years ago, there was another employee who was using Contribute regularly to update pages on the site and if we had CI/CO off it would have been a disaster.
Exactly... and in our case, we're a Dreamweaver/Contribute shop - so turning off Check In/Check Out isn't even an option. This is an advertised feature that is quite heavily broken, and has been for several versions.
If your development shop has huge 2 way bandwidth then this should not be an issue assuming that latency is decent. Most do not have this kind of bandwidth so it's best to work locally where bandwidth is cheap but that means that you would need to have the local infrastructure to support working in a group environment and in that situation Dreamweaver works great. IMO, most people should not be configuring Dreamweaver to work in a remote environment. Dreamweaver should be configured to work locally then when all are happy with what they see synchronize with the remote system -- from my experience that is how most of the Pros do it.
I'm glad I'm not the only one that thinks this isn't good enough!
It would be OK if pressing the cancel/hide buttons in the file transfer dialog actually stopped the transfer attempt and allowed us to interact with the server. I shouldn't have to force quit every 10 - 15 mins to get over the hanging.
David - I'm afraid your suggestion wouldn't help in situations like this where we as developers build sites specifically to allow clients to update it themselves (from a different location to us) using Contribute.
Fortunately on the sites where this is most common our clients don't currently use Contribute so turning off checking in/out just means I need to check with the other guys in the office.
Is anyone from Adobe able to suggest when this might be fixed?
it is a year after this thread began and no one from Adobe can comment on this?
I too have been suffering with this stupid bug for the last few versions of Dreamweaver. I have concluded that the DW CMS is just VERY lame. I have customers who use Dreamweaver and/or Contribute to manage sites we create for them and this has frustrated me and them for years. Every time a new version comes out I hope Adobe has improved their "CMS" but they never do.
Yep - I'm having to FORCE QUIT Dreamweaver normally 5/6 times a day because it gets stuck interacting with the server.
It's pretty poor that a £600 bit of professional software performs worse than pretty much any free FTP program I've tried.
yeah, how hard could it be to integrate decent FTP support?
Does everyone else have to always Force Quit to get Dreamweaver to actually cancel the File Activity?
I might start a log of how many times a day this happens then send it to Adobe!
I've also fallen victim to this issue and have tried every suggestion I could google. Passive FTP, Firewall port forwarding, switching off NAT, Combinations of different FTP Settings, etc... All to no avail. I do believe, touch wood, that I might have solved my own situation and therefore thought I'd post up.
As simple and stupid as it sounds, try using secure-FTP. As long as the server supports it, its just a matter of switching over from regular FTP and making sure the port is 22 instead of 21. It's worth a try... Now the connection is lightening quick again and I've not had a single 'waiting for server' message.
Oh, I also had the ability to stop all the FTP sessions on the server first, so you may want to do that first and start from a clean slate. Anyway, give it a go.
The connection method used doesn't seem to matter - it's a problem that seems to come from background activity internal indicators not getting reliably switched off. I have several sites which I see this happen - and we're using WebDAV over SSL.
Then again, in the Mac version at least, letting the "background activity" progress window lose focus during a transaction causes other interface bugs like the toolbars of a window becoming detached from the file window, but that's a whole 'nother issue.
I get this same problem using checkin/checkout in CS5, and it appears to happen only only on Mac OSX (or at least Mac). I transitioned from a PC and didn't have that problem, all other things being equal (of course, there were other bugs in Windows 7, so a kind of tit-for-tat).
It is absurd that Adobe hasn't fixed this critical issue. Ah, for the glory days of Macromedia....
Guess I'll just turn off checkin/checkout and hope for no overwrites.
Yeah, this is plain ridiculous. I mean - why not to put status info where it belongs, into status bar? Ok, if dreamweaver needs long minutes to resolve communication issues with a server then let it be, but why force us to click every time it happens? "I have some problems with server, should be over in 5 secs" - clik OK to dismiss popup. How pathetic is that? And how much in terms of a workforce does it require to fix it?
It's really frustrating! It's not just that it does it automatically I don't have that issue, it's just that sometimes once it's interacting, it's interacting, well at least it says it is, I see nothing changing, and it doesn't stop so I assume it never completes whatever interaction it is allegedly attempting.
Is there a way to stop this happening? My best solution throughout the years has been to use a seperate FTP program as I find it faster, more flexible, and I also found it is more likely to update the files permissions.
Still at least I paid good money for this service only to informed they want a very similar amount to upgrade to CS5.5 a short while later.
Excellent work Adobe.
The ONLY way to get Adobe's attention is if we stop buying their software. I will not buy another version of Dreamweaver until they fix this error along with a lengthy list of other recurring bugs. Money talks - stop buying their software.
Synchronisation is awful too! I really wish it would provide a list of files that have not uploaded/downloaded/failed so that I can try them again and a list of files ready to synchronise so that I could see if I wanted it to skip any of them! Another FTP program is the answer, although Filezilla doesn't have sync I have found it to be good, anyone have better suggestions for a FTP that could do everything, or perhaps even a different solution to FTP which seems quite slow. File upload in the cPanel seems a much better option!
Possibly related: trying to open an empty (zero byte) file on a testing server (local network) causes DW CS5.5 to crash ("interacting with server"). Adding any content (e.g. a line feed) to the file outside of DW fixes the issue. Possible fix for other users: check your local site file system for zero byte files and remove or edit to be non empty.
Try using the log file utility when uploading files. That gives the full info.
This is happening to me too! Very annoying - AND it won't allow my client to get in using Contribute. Any solutions to this? I am in CS$ - sheesh! I will try the force quit for now and see if I get a temporary solution anyway. Adobe - get it together! Oh I am using Lion (which I also hate)
what is the log file utility?
When synchronising files, you get the option to log the uploads. select this option and you can later look at the log file to see what files were uploaded.
Delete any files that have a zero byte size both on your computer and on the web site (if any). This worked for me.
The problem seems to be caused when you create a file but do not write anything to it, like when you first create a new file and save it to disk, before putting anything in it.
Some extensions will not let you run them unless a file is already existing, and if you save an empty file and then do not complete the add on, you are left with this problem. As soon as you synchronise all, the blank file gets uploaded.
I have one file on the server that says it is checked out by me. My client can't get into it with Contribute. How do I get rid of that check?
I don't synchronize files - I load them one at a time since my client often works on them in Contribute.
Why not just search your local and remote files for files with 0 bytes? That seems faster, or am I not understanding something?
All of my folders (directories) are zero bytes, even though they contain documents that are not zero bytes. Do directories count?