#4840 closed Feature request (rejected)
Filezilla Client do not allow to append(APPE) to existing file
| Reported by: | Parijat Bansal | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | FileZilla Client |
| Keywords: | Cc: | ||
| Component version: | Operating system type: | Windows | |
| Operating system version: | WinXP Professional version 2002 SP3 |
Description
I want to append to an existing file with the same name while uploading.
Filezilla Client do not allow to append(APPE) to existing file
I can do so using linux client
Attachments (3)
Change History (16)
by , 15 years ago
| Attachment: | untitled.JPG added |
|---|
comment:2 by , 15 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
The resume operation (rfc 3659) is different than append(rfc 959).
However the way resume implemented it works fine and I can see from logs that it sends APPE. What it does is actually sends only remaining part of file. If a local file say abc.dat is of 10 KB and I have a file with same name abc.txt of 7KB at server than resuming file will append remaining 3KB and makes file 10KB.
Append is suppose to make the file 10KB+7KB=17KB
Filezilla server works perfectly in explained way and as per RFC 959 this is expected behaviour too. Hence I think the ticket raised is perfectly valid.
I feel that resume should be implemented as per RFC 3659 (using REST and STOR). In fact rfc 3659 says that its not recommended to use APPE or STOU after REST. But I think filezilla have its own reason to do resume in its way. In fact few other clients also do it like this such as winscp. My issue is that it should have an option to append to file rather than resume which are completely seperate operation.
Please feel free to let me know I am not making myself clear.
Regards,
Parijat Bansal
comment:3 by , 15 years ago
actually, resume is not working in 3.2.8.1. it only does STOR, especially on ECONNRESET. (ticket #4924) it hasn't been working for a while now (1-2 months).
comment:4 by , 15 years ago
| Status: | reopened → moreinfo_reopened |
|---|
I don't suppose you got the required logs?
comment:5 by , 15 years ago
| Status: | moreinfo_reopened → reopened |
|---|
if you mean logs of the ECONNRESET and resume failure, that happens only after about 90% of a 2.9GB file upload and takes about 2 days to reproduce. no I didn't get a log. I am generating logs now.
If you mean logs of it ignoring the upload settings, I can try to reproduce that by making changes to the settings in filezilla.
by the way,
If a file exists on the server, and it is 329MB, but I am uploading 2.9GB, it doesn't resume like it is supposed to. it says "all done".
I have a debug log of that.
http://JesusnJim.com/z/filezilla-upload-all-done-too-soon.log
you really need something where you can attach files to your tickets!
sourceforge has a nice ticketing system that can do that (the blue one).
comment:6 by , 15 years ago
| Status: | reopened → moreinfo_reopened |
|---|
you really need something where you can attach files to your tickets!
There is, scroll up. Please attach the log.
by , 15 years ago
| Attachment: | _filezilla-upload-all-done-too-soon.log added |
|---|
filezilla log, upload done too soon, 2.9GB file uploaded to 329MB file
by , 15 years ago
| Attachment: | filezilla-ECONNRESET-upload-resume-breaks.log added |
|---|
filezilla log - ECONNRESET causes upload resume to do STOR
comment:7 by , 15 years ago
| Status: | moreinfo_reopened → reopened |
|---|
I could not make a debug log of changing settings. also, my settings of transfer|default file exists action to resume has reverted back to default somehow(?). please fix.
comment:9 by , 15 years ago
| Resolution: | → rejected |
|---|---|
| Status: | reopened → closed |
According to the log the transfer gets interrupted midway. Read http://wiki.filezilla-project.org/Network_Configuration#Timeouts_on_large_files
Screenshot