When I upload files from inside a zip file to a remote sftp drive, and those files are greater than 60 Kb (I don't know the exact threshold) the files get corrupted. The resulting uploaded file seem to contain random chunks of binary data, and even the listing of the folder! For example I uploaded jquery-ui.min.js (200 Kb) and the resulting file contains the listing of the remote directory mixed with null characters and non ascii characters. I noticed the file size threshold because I uploaded hundreds of files from inside a zip file, and only the larger ones, which were randomly spread over different folders, were damaged. Reproducible: Always Steps to Reproduce: 1. Find a local zip file containing text files (small ones with a few Kb, and larger ones, above 100 Kb). 2. Enter the zip file with krusader. 3. In the other pane, connect to an SFTP drive. 4. Copy the content of the zip file to the SFTP drive. Actual Results: The files larger than 60 Kb (more or less) arrived mangled (content damaged). Expected Results: The files should be identical in the remote server and inside the zip file.
Created attachment 76378 [details] Sample damaged file
Does it also happen with other archive types (those where the krarc:// protocol isn't used) ?
zip and rar corrupted. 7z and tar.gz good. (In reply to comment #2) > Does it also happen with other archive types (those where the krarc:// > protocol isn't used) ?
Created attachment 76692 [details] Test file, zip format. Content gets corrupted. Try to enter this file with Krusader and copy the contained folder to an SFTP drive. The larger file gets corrupted.
Created attachment 76693 [details] Test file, 7z format. Content does NOT get corrupted. Try to enter this file with Krusader and copy the contained folder to an SFTP drive. The files arrive correctly to the server.
confirmed in 2.4.0-beta3
I did some testing and found out that the chunk size in which the data is sent to the sftp ioslave determines whether the bug occurs: 16kb - works 32kb - works 63kb - works 64kb - corrupt data 65kb - works 127kb - works 128kb - corrupt data 129kb - works Another observation: the corrupt uploaded file apparently contains ssh protocol data. Reassigning to kio/sftp.
*** This bug has been marked as a duplicate of bug 312320 ***
I can still reproduce this on current git, so apparently this isn't a duplicate of bug 312320 after all. Reopened.
I need to look into that as soon as possible. We are working on libssh 0.6 right now.
This only happens if you copy from zip to sftp, but not from the normal filesystem? So if you unzip the files and upload them, then everything is fine?
Need answer to question in comment #11...
Created attachment 82446 [details] testprogram
I'm sorry for the delay. The file source doesn't matter, the chunk size in which the data is handed to the sftp ioslave is decisive (see comment 7). I have added a small test program in comment 13.
*** Bug 323195 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > I'm sorry for the delay. > The file source doesn't matter, the chunk size in which the data is handed > to the sftp ioslave is decisive (see comment 7). > I have added a small test program in comment 13. I can only duplicate copying file from a zip file to sftp causing corruption. It works fine if I first extract the file before copying it. The program you attached does indeed show the corruption, but that is an added dimension I do not want to debug ; so I will simply look into why the file gets corrupted when being uploaded from a compressed archive for now. BTW, if you are have application code that uses KIO, then make sure it does NOT connect to the KIO finished signal. That signal is internal. As documented you should connect to the "result" signal instead.
After further testing I can only reproduce this problem whenever the krach protocol, which seems to be part of krusader, is in use. If I use zip protocol to open the same file and transfer its contents to an sftp server I do not see any corruptions. IOW, if I download the test.zip file attached above and copy "soundmanager2.js" by using the zip protocol, zip:/tmp/test.zip/test/soundmanager2.js to sftp://localhost/temp/, I do not see the corruption. However, if I repeat the same thing using the krarc protocol, krarc:/tmp/test.zip/test/soundmanager2.js then I see the corruption. So as far as I can tell so far, the issue is specific to using the krarc protocol.
Jan, if I understand the analysis in comment #17 correctly, this bug should be assigned back to Krusader developers, right?
Jan, if you can provide the information requested in comment #18, please add it.
No response, reassigning.
(In reply to Dawit Alemayehu from comment #17) > After further testing I can only reproduce this problem whenever the krach > protocol, which seems to be part of krusader, is in use. If I use zip > protocol to open the same file and transfer its contents to an sftp server I > do not see any corruptions. IOW, if I download the test.zip file attached > above and copy "soundmanager2.js" by using the zip protocol, > zip:/tmp/test.zip/test/soundmanager2.js to sftp://localhost/temp/, I do not > see the corruption. However, if I repeat the same thing using the krarc > protocol, krarc:/tmp/test.zip/test/soundmanager2.js then I see the > corruption. > > So as far as I can tell so far, the issue is specific to using the krarc > protocol. I assume the reason for this is that krarc sends the data in one of the affected chunk sizes and zip doesn't. Although this is just an assumtion atm. - I don't remember whether I verified the chunk sizes which krarc/zip send. Also I haven't yet tried to reproduce this again. But if it's really because of different chunk sizes, then the bug is in the zip kioslave and krarc simply triggers it.
can't reproduce anymore with KF5 and current master.