I have searched this forum and found several related topics but none of the provided solutions seem to work for me.

I have mapped my remote web server Document Root directory as a network drive on my local development machine.
It uses a VPN link (OpenVPN) as a secure tunnel.

The problem is that PhpED just hangs on some random folder while it's starts the initial scan.
Right now it's a hanging on a folder with only 2 .ini files.
I can browse all the folders with no problem in Windows Explorer.

Some details:
Server:
Samba Version 3.0.33-3.15.el5_4.1

Desktop:
Windows 7
PhpED 5.9

As a side note:
I have this specific setup because the file needs to be to be available locally for debugging purposes.
And I dislike having to constantly press the CTRL+SHIFT+s button to sync the local and remote file when using for example sftp.

After some more digging I see PhpED is still actively scanning the project root tree.
The (rather large) Zend Framework directories are the ones that take up so much time.
The footer info in PhpED "scanning <current/scan/directory>" just doesn't reflect the real directory that is scanned.

I might for now just exclude these directories.

I suspect this way of working may just continue to provide you with frustration.

I used to work exactly the same way but I found phpEd just cant get the project info it needs from a remote server fast enough, and everytime I start it up I got fed up waiting for the scanning to take place. Not phpEd's fault - just a consequence of using that functionality with a remote file system. I also experienced slow file access / timeouts when using a remote server as a network drive, which I didnt experience when using the source as an ftp connection.

I also found the sync feature to be a real problem when using a framework as it doesnt actually remove files, and this led to quite a degree of confusion, especially when dealing with a framework that uses autoloaders.

In the end I accepted that phpEd works best operating locally, there are fewer hoops to jump through, and that moving from local to remote server is better dealt with by svn (or git or whatever floats your boat) by just doing a commit of local changes, and checkout latest version on remote server.

So I use virtualbox now and since I accepted this fate my life has been much happier!

cr0wn3r: thank you for providing a new perspective on this "issue".

Sometimes you are just focused too much on trying to solve the problem at hand that you forget to look at other options.