| Summary: | dolphin copy folder corrupts file md5sum | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Alexander <alexander.nofamilyname> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | critical | CC: | adawit, adrian, axel.carl.mueller, cfeck, frank78ac |
| Priority: | NOR | Keywords: | triaged |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | screen of the changed md5sum | ||
|
Description
Alexander
2012-06-23 17:54:52 UTC
Created attachment 72077 [details]
screen of the changed md5sum
Does the new file have the same size as the original file? (In reply to comment #2) > Does the new file have the same size as the original file? Yes it does have exactly the same size, it is not a partial copy or something like that. I cant reproduce it with all files/folders but with some all the time. (In reply to comment #3) > (In reply to comment #2) > > Does the new file have the same size as the original file? > Yes it does have exactly the same size, it is not a partial copy or > something like that. > I cant reproduce it with all files/folders but with some all the time. What type of files are these "some" you can reproduce this with all the time? > What type of files are these "some" you can reproduce this with all the time?
What normally gives this error is downloading a movie with Ktorrent, then after the download is finished (Ktorrent is definitely not running anymore), then copy the whole folder to another location. If i copy only the movie file the md5sum is not changed. Tried it for example with the Big Bucks Bunnie movie.
Today it happened on an album and the only file corrupted from the tracks was the one containing () in it. Resetting assignee to default as per bug #305719 I cannot reproduce this. Could you please try with a newer version of Dolphin? A bit more detailed steps: 1. Download the Big Buck Bunny torrent. Magnet link: magnet://?xt=urn:btih:88b2c9fa7d3493b45130b2907d9ca31fdb8ea7b9&dn=Big+Buck+Bunny+1080p&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80&tr=udp%3A%2F%2Ftracker.istole.it%3A6969&tr=udp%3A%2F%2Ftracker.ccc.de%3A80 2. Once downloaded, check the MD5 of the movie file (“md5sum *.avi” inside the torrent folder). It will be ‘223991c8b33564eb77988a4c13c1c76a’. 3. Copy the downloaded folder inside a test folder (e.g. ‘~/bug302415’). 4. Rename this copied folder into something with “()” in it. For example: “Big Buck Bunny (surround)”. 5. Get the MD5 of the movie file inside. It will still be ‘223991c8b33564eb77988a4c13c1c76a’, as expected. 6. From the test folder, copy the renamed folder (“Big Buck Bunny (surround)”) and paste in the place. You will be asked to choose a name for the new folder, so choose some variation still with “()” in it (e.g. ‘Big Buck Bunny asdf (surround)’). Wait for the copy process to finish. 7. Check the MD5 of the movie file inside ‘Big Buck Bunny asdf (surround)’. You can actually compare both folders easily by running “md5sum */*” from the test folder. Expected results: the MD5 sums are the same. They are for me. I did noticed an odd behavior: the info panel shows far less details for the movie files in the testcase folder (only that it’s AVI, the size and the modification date). But that’s not the point of this report. I encountered similar problems during file copying. I think the problem is not related to any files/folders with "()" in their name. The problem occurred only for me when I copy large files (several hundred MBs) over the network. I could reproduce it with a samba share and an OpenAFS network volume. In both cases, the target file has the wrong md5sum. I compared the bytes of the original and the (corrupt) target file and it was obvious that the block ordering was incorrect. e.g. Original Block 1,2,3,4,.. Target Block 1,4,3,2,.. Thus, file size is still correct but md5sum not. Thanks for the comments. Like Adrián, I have not seen the problem myself yet. In any case, it's most likely not a Dolphin issue because Dolphin does not do the actual copying itself. KIO and the kioslaves are responsible for this -> reassigning. (In reply to comment #9) I am using KDE 4.8.5 (Kubuntu 12.04). I tried this from a samba share, but I am unable to duplicate this problem. Do you still have this issue with the latest stable version of KDE, v4.10 or higher? (In reply to comment #12) > I tried this from a samba share, but I am unable to duplicate this problem. > Do you still have this issue with the latest stable version of KDE, v4.10 or > higher? Unfortunately, I cannot update to v4.10 (still on Kubuntu 12.04). But I rerun my tests. So far the copied files were *not* corrupted using a smb share. But I experienced corruption (wrong md5sum) in case of a OpenAFS share. The OpenAFS share is mounted into my local file system. Copying from the command line does work w/o any file corruption. Only copying from within Dolphin does not work. Perhaps Dolphin does not recognize the folder as a mounted network share and therefore something goes wrong (just guessing)? (In reply to comment #12) > I tried this from a samba share, but I am unable to duplicate this problem. > Do you still have this issue with the latest stable version of KDE, v4.10 or > higher? I'm using Debian and are still on KDE 4.8.4. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |