FTP gone wrong!
Sometime today, I've managed to screw up my PHPStorm project settings. Long story short, I've reached a position where I can delete from the FTP server, but can't replace anything, at least not using the built-in FTP host. I don't know if it's permissions or anything, but it seems wrong to me that the autodetect of the root folder is finding a folder name. I think it's some kind of permissions issue, or relative deployment folders but I can't put my finger on what it is. I'm running the risk of deleting the whole website at this rate. I've never come across an issue where I can delete but not write. No problems with other FTP clients.
Anyone got any ideas of where to look?
Please sign in to leave a comment.
Please share screenshots of the Connection and Mapping tabs of the deployment configuration, and also listing of the FTP root.
Although it worked from my laptop at home, my desktop was just frustrating me completely.
I finally figured out that the issue was that I'd set up as FTPS on the desktop, and plain FTP on the laptop. The data channel protection method (only available in FTPS) was set to private. However, this setting still allowed me to delete a file without the ability to replace it. This was the cause of the panic. By setting the data channel protection method to default, I was able to write files.
Presumably this is because the DELETE is issued over the command channel, whereas the replacement file is sent over the data channel, although the mode was set to PASV because we are behind several firewalls (hardware and software!)
Perhaps a test for this "feature" should be employed? I believe that private was the default setting for this on creating the remote host profile.
Sounds like an unpleasant issue, really.
Could you please tell a little bit more about it?
You have mentioned DELETE command, how exactly did you achieve that, did you delete a local copy of file and it was deleted after the sync operation or you just opened the "Browse remote host" and deleted the file? Or, the worst, was the file deleted during upload (deleted but not uploaded a new copy) operation?
In fact, logs could shed some light on the situation. Unfortunately, there is no way to enable extended logging backwards but probably, something useful was logged already. Please feel free to collect log files (Help > Compress logs and show) and contact support, so we could check these and provide some RCA if possible.
What I did was to make a quick and trivial edit by clicking to open the file from the browse remote host panel.
When I clicked upload, the process appeared to DELETE the original file (probably using the FTP command DELETE), then attempt an PUT which failed due to the data channel protection method setting described above.
The correct sequence of events should have been to attempt a PUT of the changed file to a temporary file name in the target directory, on success DELETE the original file, then RENAME the temporary file to the original filename. On failure to PUT into the target directory, the process should abort. This should protect (1) the original file from being deleted, (2) the edits made to the file being lost if the DELETE is unsuccessful (it would remain on the server under the temporary filename).
It makes sense not only in a case similar to yours, but generally, considering there can be connection issues and other problems. Please vote: https://youtrack.jetbrains.com/issue/WI-20248
Upvoted. Can't believe that the issue has been ongoing for so long, although I'm not surprised that there are a considerable number of posts about it. It's the sort of issue that IS going to crop up, especially on sites with a high access frequency, limited caching and file locking.