getting sick of seeing "Failed to transfer file" "could not determine the type of file"

The auto upload is a great feature but it seams to be failing quite often for me.  So far it has failed 6 times today

My usual workflow is:
* write something in the editor,
* move the mouse up to firefox, click once to gain focus
* push F5 to refresh the page.

In the background phpstorm will usually save the file and automatically upload it to the server via FTP.

But lately Im seeing a lot of:
[8/28/12 12:07 PM] Failed to collect files: Could not determine the type of file ""

[8/28/12 12:45 PM] Failed to delete folder '/server/httpdocs/somefolder': could not determine the type of file "".

[8/28/12 2:06 PM] Failed to transfer file '/home/me/PhpStorm_projects/project/core/modules/jrSomemodule/templates/stats.tpl': could not determine the type of file "".

it sucks because each time it fails i have to:
* focus back on the editor
* right click and locate "upload to"
* back to the browser
* refresh

In short a bunch more steps because this fails.  Anyone have any idea as to why it might be failing.  I have tried changing the 'advanced options'->passive mode to ON but that doesnt stop this issue.

Hoping there is a way to fix it.  running on PS-121.110  but it was happening on the previous EAP and have seen it before in the past too, just not as often.




This happens only on autoupload and never on upload action, doesn't it? Please create an isue and attach debug ftp log.

Best regards,


correct it only happens on autoupload.

There is a _very_ similar request here:

The only real difference is that in that feature request the wording was "because its not a file"  which has now changed to "could not determine the type of file".

Up to 14 fails so far today.

Ill put that logger in for tomorrow, only got an hour or so of work left in me today.


seams to have days on and off.

Today the 'failed to transfer' is happening.  I have added the log to the ticket.

The portion of code from the log that looks to be related is this:

2012-09-04 14:25:06,056 [12336997]  DEBUG - ains.plugins.webDeployment.ftp - > PASV
2012-09-04 14:25:06,056 [12336997]  DEBUG - ains.plugins.webDeployment.ftp - 421 Timeout.
2012-09-04 14:25:06,058 [12336999]   WARN - ins.webDeployment.TransferTask - Copy: file:///home/ussher/PhpStorm_projects/Jamroom5/core/modules/jrMailer/include.php to /modules/jrMailer/include.phpfailed
org.apache.commons.vfs2.FileSystemException: Could not determine the type of file "".
    at org.apache.commons.vfs2.provider.AbstractFileObject.getType(
    at org.apache.commons.vfs2.provider.AbstractFileObject.exists(
    at com.jetbrains.plugins.webDeployment.DeploymentPathUtils.refreshRemoteFile(
    at com.jetbrains.plugins.webDeployment.DeploymentPathUtils.refreshRemoteFile(
    at com.jetbrains.plugins.webDeployment.RemoteHostTask$4.findRemoteFile(
    at com.jetbrains.plugins.webDeployment.TransferTask$2.findRemoteFile(
    at com.jetbrains.plugins.webDeployment.TransferOperation$Copy.execute(
    at com.jetbrains.plugins.webDeployment.TransferTask.executeOperations(
    at com.jetbrains.plugins.webDeployment.RemoteHostTask$5.compute(
    at com.jetbrains.plugins.webDeployment.RemoteHostTask$5.compute(
    at com.jetbrains.plugins.webDeployment.connections.RemoteConnection$2.compute(
    at com.jetbrains.plugins.webDeployment.connections.RemoteConnectionPool$RemoteConnectionImpl.executeServerOperation(
    at com.jetbrains.plugins.webDeployment.connections.RemoteConnection.executeServerOperation(
    at com.jetbrains.plugins.webDeployment.RemoteHostTask.doRun(
    at com.jetbrains.plugins.webDeployment.AutoUploadComponent$FileListenerImpl$
    at com.intellij.openapi.progress.impl.ProgressManagerImpl$
    at com.intellij.openapi.progress.impl.ProgressManagerImpl$
    at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(
    at com.intellij.openapi.progress.impl.ProgressManagerImpl.runProcess(
    at com.intellij.openapi.progress.impl.ProgressManagerImpl$
    at com.intellij.openapi.application.impl.ApplicationImpl$
    at java.util.concurrent.Executors$
    at java.util.concurrent.FutureTask$Sync.innerRun(
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    at java.util.concurrent.ThreadPoolExecutor$
    at com.intellij.openapi.application.impl.ApplicationImpl$1$
Caused by: Broken pipe
    at$$YJP$$socketWrite0(Native Method)
    at sun.nio.cs.StreamEncoder.writeBytes(
    at sun.nio.cs.StreamEncoder.implFlushBuffer(
    at sun.nio.cs.StreamEncoder.implFlush(
    at sun.nio.cs.StreamEncoder.flush(
    at org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.disconnect(
    at org.apache.commons.vfs2.provider.ftp.FTPClientWrapper.listFiles(
    at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetChildren(
    at org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildFile(
    at org.apache.commons.vfs2.provider.ftp.FtpFileObject.getInfo(
    at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(
    at org.apache.commons.vfs2.provider.AbstractFileObject.getType(
    ... 27 more
2012-09-04 14:25:06,059 [12337000]  DEBUG - ins.webDeployment.TransferTask - finished
2012-09-04 14:25:06,062 [12337003]  DEBUG - t.connections.RemoteConnection - Releasing one of the connections to


Is there a ticket for this now?
It is happening to me as well. It happens on manual uploads for me. Seems a bit more likely when
things have been idle. Very seldom, if ever, have I seen it happen twice in a row.
It is a nuisance, no doubt about it.

ps. build 121.285 Windoze XP


Please create separate issue and attach collected debug logs there.


I did submit a ticktet. But I can't edit it until it clears, meanwhile one more observation.
The full message starts 'Failed to collect files:'. The collection indication spins for
a relatively long time when the bug occurs. It is much quicker to complete when
the upload works.


Could you provide link to that ticket, or at least your nik on youtrack?


This one's been open longer and has a bunch more resources/logs attached to it.


its being particularly annoying today


A solution that worked for me was uncheck Preserve time stamps located here: 

Tools=> Deployment => Options => Preserver Time Stamps

Hope that helps