I'm running into some pretty serious issues, and I'm pretty sure its not me (this time :-)
Maybe not a P1, but certainly up there.
This worked FINE with 6.7beta, and a few subsequent nightlies... then it broke and stopped working. I confirmed it still
does NOT WORK with 6.7RC3.
The problem is this:
setup/configure FTP or SFTP in a project. (php in my case)
(ftp/sftp seem to have the same problem)
create a new file, and right-click upload it.
Right-click the same file, and DOWNLOAD it.
The ftp window suggests everything looks ok, and it downloads it. Then it throws an unknown failure... AND appears to
DELETE the file from the project window. (so no download, AND your local file gets clobbered....)
*again, this exact same test works fine with 6.7beta, and uploads appear fine...
(this is not a filesystem full situation, and I can make it work reliably with 6.7beta, and fail with 6.7rc3)
Here is the error...
250 CWD command successful.
250 CWD command successful.
200 PORT command successful.
150 Opening BINARY mode data connection for EmptyPHP.php (111 bytes).
226 Transfer complete.
221-You have transferred 111 bytes in 1 files.
221-Total traffic for this session was 571 bytes in 1 transfers.
221-Thank you for using the FTP service on xxxxxxxxxxxxxxxxxx.fmr.com.
file var/tmp/xxxxxxxxxxxxxx/etc/rc3.d/EmptyPHP.php Cannot download file EmptyPHP.php (unknown reason).
Runtime: 656 ms, transfered: 0 file(s), 0 KB
1 thing the might play into this is a potential interaction with SVN? the working test with 6.7beta is without svn,
whereas the broken tests do have SVN in play. Should be an issue, but you never know. We need to be able to understand
the "unknown error" better. please let me know what I can do to provide further debugging info.
I added the svn client to 6.7beta and attempted the download of a file... same error.
The SVN piece is somehow trashing the ftp/sftp download.
How to proceed?
Same for me. It seems it happened after applying last patches through automatic updater. It's awful, because downloaded
file gets deleted on both local and remote machines.
Product Version = NetBeans IDE Dev (Build 2010-12-28_18-04-29 )
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.6.0_18
Runtime = Java HotSpot(TM) Client VM 16.0-b13
I have a similar issue. I do not get any errors like the person above. I'm using SFTP. My Netbeans specs above. This issue is still around in the CI builds from Hudson.
If I try downloading a file from the server to my project, Netbeans deletes the local copy of the file. If I try to download the file again, by clicking on the download context menu item for the folder, all the remote files for the folder are listed except for the local file that got deleted. So, I have to use an external file transfer tool to get the deleted file.
This bug maybe part of an SVN issue because when Netbeans deletes the file, it is marked for deletion on next commit in subversion. Usually when a file is deleted from the filesystem (that is part of a SVN repo), the file is not marked for deletion.
Product Version: NetBeans IDE Dev (Build 201102070000)
Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09
System: Windows XP version 5.1 running on x86; Cp1252; no_NO (nb)
This is still an issue in the latest version. I got this in a project using FTP and subversion.
I can confirm: This is still an issue in Netbeans 7 beta 2, using FTP / SFTP and Subversion.
This is really urgent IMHO.
I could not reproduce this bug after upgrading to NetBeans IDE 7.0 (Build 201104080000) = RC1. No files were deleted when downloading by FTP nor SFTP.
Is it resolved?
Same problem here:
Versão do produto: NetBeans IDE 7.1.2 (Build 201204101705)
Java: 1.7.0_05; Java HotSpot(TM) 64-Bit Server VM 23.1-b03
Sistema: Windows 7 versão 6.1 executando em amd64; Cp1252; pt_BR (nb)
Diretório de usuário: C:\Users\Andrew\.netbeans\7.1.2
Diretório de cache: C:\Users\Andrew\.netbeans\7.1.2\var\cache
Other problem: Too many CWD. I can´t see the PUT command on the Output log. I think, that´s the problem.
I forgot that I commented on this bug. I think it has been fixed since 7.0 because I no longer have this issue.