㈠ ftp文件傳上去大小變成0
226-Maximum disk quota limited to 204800 kBytes Used disk quota 211189 kBytes, available 0 kBytes
磁碟配額用完了
㈡ ftp上傳的文件大小全是0kb
使用二進制上傳，如果再不行就是你的網關屏蔽了FTP協議。不過FTP上傳慢，可以壓縮後上傳，然後在線解壓一下就行了，asp，PHP都有對應的在線解壓工具，只有單個文件。
㈢ ftp上傳文件大小為0
出現這個問題原因可能如下：
1、空間使用量已經達到設置的最大空間容量，請加大空間或者刪除部分文件。
2、假如帳號FTP_123對應目錄e:\ftproot\zmfzzf\aa的空間（20M），帳號FTP_456對應e:\ftproot\zmfzzf\aa\a（20M），用帳號FTP_456刪除帳號FTP_123上傳的文件，這時就會在帳號FTP_123上存在空間刷新不過來的情況。
當用帳號FTP_123上傳的文件大小達到20M（空間已滿），此時你用帳號FTP_456刪除了FTP_123帳號上傳的文件，但實際FTP_123帳號空間已使用容量還是20M，所以再用FTP_123上傳文件時就會出現上傳文件顯示0位元組。遇到這樣的問題請及時與客服聯系解決。
因此，建議客戶用同一個帳號上傳和刪除文件。否則出現上述問題客服不承擔任何責任。
㈣ ftpget文件的時候failurestream文件變成了0大小
需要設置文件上傳的方式，即調用ftpclient的方法setfiletype()，並傳入參數FTP.BINARY_FILE_TYPE，如下是FTPClient的API中關於這個方法中參數的說明原文：
Sets the file type to be transferred. This should be one of FTP.ASCII_FILE_TYPE , FTP.BINARY_FILE_TYPE, etc. The file type only needs to be set when you want to change the type. After changing it, the new type stays in effect until you change it again. The default file type is FTP.ASCII_FILE_TYPE if this method is never called.
意思是ftp文件上傳時，需要指定filetype，並且是FTP.ASCII_FILE_TYPE , FTP.BINARY_FILE_TYPE兩個中其中一個，如果不設置（如果不調用setFileType方法），則默認的文件上傳方式是FTP.ASCII_FILE_TYPE。
往往當上傳到伺服器時的文件是0KB時，問題就在這個默認值上，這也跟FTP伺服器的設置有關系（猜測是與FTP伺服器的安全方面的設置相關），只需要調用一下setFileType方法並指定參數為FTP.BINARY_FILE_TYPE就可以了
㈤ 打開ftp本地目錄文件夾大小0怎麼辦
您好，/etcc/pure-ftpd/pure-ftpd.conf 這個是linux上的目錄么，怎麼重啟pure-ftpd 服務 ，謝謝了~
估計是網路問題,但不排除伺服器的影響.
㈥ 為什麼FTP上傳的文件是0位元組，FTP上傳文件0位元組的解決辦法
使用同一個電腦，同樣的軟體對另一個網站的ftp操作確一切正常。這個不能正常ftp傳輸的網站無論上傳或下載後的文件大小變成0位元組。在ftp環境下可以刪除遠程的文件。另外，進入默認的文件夾後根本無法進入上級和下級目錄，既無法打開。
有時候登錄時還不能正常進入默認遠程文件夾。使用leapftp登錄後的右上部的往根目錄的箭頭也不見了。
後來使用flashfxp、dreamwere、ie去登錄ftp地址，其結果都相同。與虛擬主機服務商反復聯系。虛擬主機的空間尚存在比較大的餘量。文件空間未超過設定值。服務商確認那邊沒問題。虛擬主機服務商又說我的電腦有問題。我又把我的電腦一鍵恢復了。還是沒有解決。偶然的機會去外地公差，在外地他人的電腦里把我的網站ftp修改成功了。可見兩頭沒問題，而在異地使用ftp可以正常將文件上傳和修改了。
故障信息代碼見下圖：
錯誤代碼一錯誤代碼二錯誤代碼三
問題的主要表現是登錄後馬上打開www文件夾。可以看到此文件夾里的文件，可以進行刪除。但是，不能對其進行其他任何操作。如果上傳文件大小為0。
打開上級文件夾或下級文件夾都看不到該文件夾里的文件或文件夾。
最後，虛擬主機服務商建議修改我的電腦的首選dns伺服器地址和備用dns伺服器地址。還是沒有解決。最後，找到了寬頻介入服務商，在她那裡對接入設置進行了調整。問題得到了解決。誰能想到寬頻接入商還會影響到ftp的傳輸。看來，虛擬主機系統的不同（windows、unix等）和寬頻接入的設置都會影響到ftp的正常傳輸。
㈦ linux 用ftp傳文件，傳上去的文件大小為0.
首先確認一下伺服器上用的什麼FTP軟體？ vsftp？
簡單的方法就是重啟ftp服務，比如service vsftp restart。
然後再試。
客戶端也可以換其他ftp軟體，或者用windows自帶的ftp試。
㈧ ftp上傳的文件為0kb怎麼辦
出現這個問題時，用戶就不知道如何處理了，上傳到底是成功了還是失敗了呢？不確認…如果安裝了，會不會在某功能方面有問題呢？也不確認…
其實出現這個提示主要與空間的設置有關，可以看一下，出現這些黃色警告信息的文件多是0位元組。有些空間對0位元組文件比較敏感，當它發現上傳的文件是0位元組時，就會標一個警告信息。
出現這種提示時，可以這樣操作，就是找一個報警的文件，比如上圖中html下的某個0位元組文件；然後到空間上找到對應目錄core/html 在這個目錄下，看一下剛才的0位元組文件是否已經成功上傳？如果已經上傳了，則在CuteFXP上傳序列中刪除這個上傳文件即可。多數情況下，是已經上傳成功了，因此，大可放心。
當然，既然是多數情況，肯定也有少數情況。如果空間中對應目錄下，這些0位元組文件沒有上傳成功，則需要與空間商溝通一下，讓他們幫你把這些文件上傳到空間去，這樣也是可以解決問題的。
或者使用專門的編輯軟體，如Editplus或Dreamweaver編輯一下這些0位元組的文件，在裡面放個值，如0，再保存後，就不是0位元組文件了，就可以正常上傳的。
據暗香統計，目前這樣的空間已經越來越少了….
㈨ ftp上傳文件失敗，長傳文件大小為零位元組！
上傳時出現同名零位元組的文件，應該是伺服器端建立了一個臨時文件准備接收數據，但是出現錯誤，就無法上傳了。此時FTP客戶端和伺服器建立的tcp網路連接還在，伺服器端仍然在等待客戶端上傳數據，在等待一段時間收不到數據以後，伺服器端才會關閉這個鏈接，同時刪掉臨時文件，在這段時間內你用什麼FTP程序上傳都會出錯，因為伺服器端的臨時文件還在，無法新建同名文件，伺服器還在等你寫入上一次的數據到最初的臨時文件。
過了一段時間後，伺服器等不到你的數據，關閉了最初的有錯誤的連接，刪掉了臨時文件，你再上傳，就沒問題了，就可以上傳成功，因為可以再次新建一個臨時文件了。這就是你看到的這個錯誤的原理。只要以後你上傳沒出錯，應該不會再出現問題，如果還出問題，就建議聯系FTP伺服器的管理員協助你處理。
由於不同FTP伺服器處理方式不同，我給出的只是一種可能的原理，並不一定就是你這個錯誤的實際情況，如果有其他新的情況可以繼續追問，幫你繼續分析。