Hi! I think that from maybe KDE-3.5.2 to 3.5.5 a problem arose, i think maybe from kdebase-kioslaves. The issue is kioslaves calculates time left to copy something to a pen in a wrong way. So says the copying is finished, tough the pen is still blinking. The worst problem derived from this is that if i try to unmount the pen, it does so very quickly, it doesn't make me wait, and most of the time, after it shows the pen as unmounted, the pen's led is still blinking, and removing it causes data corruption. The old way were a progress dialog appeared till the pen stopped transfering worked very nicely. I know probably this isn't up to gentoo's developers, but kde's, still i wanted to report it, cause it's a serious issue in my point of view. Reproducible: Always Steps to Reproduce: 1.mount the pen with kde 2.copy some big files and wait for the progress dialog to close, the pen's led should still be blinking 3.unmount the pen with kde, the pen will still be recording data after apparently being unmounted Actual Results: sometimes data corruption, or data that i put in the pen is not available Expected Results: put up a progress dialog of the unmount, and don't tell it's unmounted until it really is
(In reply to comment #0) > I know probably this isn't up to gentoo's developers, but kde's, still i wanted > to report it, cause it's a serious issue in my point of view. Indeed, this belongs to http://bugs.kde.org/
Please check https://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity. The behaviour you're reporting doesn't cause data loss - what causes data loss is removing a pen while the write led is still blinking. Open a bug at kde bugzilla and post a link to the bug here.
(In reply to comment #2) > Please check https://bugs.gentoo.org/page.cgi?id=fields.html#bug_severity. > The behaviour you're reporting doesn't cause data loss - what causes data loss > is removing a pen while the write led is still blinking. > > Open a bug at kde bugzilla and post a link to the bug here. > Of course, but it does cause data loss if you don't look at the pen. Wich happened to me the first or second time, and to people i know who use gentoo. It's not normal for a feature to be working fine, and then this happening. If I find a way to fix this, could i submit the patch to the gentoo kde team? KDE team seams to be fixing this, but since they're busy with kde4 it may be some time till it gets fixed. I tryed 3.5.7, it doesn't unmount, but shows some confusing error messages. Best regards.
I've reread your comment and realize I missed one important thing: your bug is about the copy, but it should be about the unmount process. Anyway, I think this behaviour is expected with buffered writes. Are you using hal? What is the filesystem on the pen? Have you tried using the sync option with the pen? About applying a patch locally, the Gentoo policy is to try to follow upstream as closely as possible. If your patch works, upstream is unresponsive, the Gentoo kde team considers it important and you can convince a member to apply it, then it can be done.
(In reply to comment #4) > I've reread your comment and realize I missed one important thing: your bug is > about the copy, but it should be about the unmount process. Anyway, I think > this behaviour is expected with buffered writes. > Are you using hal? What is the filesystem on the pen? Have you tried using the > sync option with the pen? I tried the sync option, it should be on by default, cause now it gives me real transfer rates :) Anyway, it doesn't solve the problem, and yup, i'm complaining about the unmounting, tough the copy could be better. > > About applying a patch locally, the Gentoo policy is to try to follow upstream > as closely as possible. If your patch works, upstream is unresponsive, the > Gentoo kde team considers it important and you can convince a member to apply > it, then it can be done. > Ok. I'll see what i can do. I suggested this because the gentoo team seems to follow upstream, but if the kde team screws up, you usually fix the things necessary to get a working system.
I agree that this behaviour should be corrected - even command line tools such as umount block until the device has been synced before returning. We will look into patching this for 3.5.7 before stabilising it if possible.
Fixed in 3.5.8. Unmounting works properly, what remains is the eject issue, see bug 186028 for more information.
