Summary: | Okteta crashes when choosing export | ||
---|---|---|---|
Product: | [Applications] okteta | Reporter: | Jared Barneck <rhyous> |
Component: | general | Assignee: | Friedrich W. H. Kossebau <kossebau> |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | FreeBSD | ||
Latest Commit: | Version Fixed In: | 0.6.1 | |
Sentry Crash Report: |
Description
Jared Barneck
2011-01-28 06:31:23 UTC
Thanks for the report. Could reproduce. Seems you were trying to export to a location in your filesystem where you do not have write rights, correct? Because this crash only happens for me if a choose a folder on the filesystem where I cannot write to. And the call to QIODevice::errorString() in the backtrace you gave hints that this or a similar problem is the reason. So as "workaround" for now just export to locations where you can save to, that should work :) Hah! I was going to add this info this morning. Yes, I didn't have rights. It worked when I moved to a location with rights, but it was late, and I had lost data not backed up, so I had done a dd of the drive and sure enough the file was there in the dd dump even though it was technically deleted, so I was trying to pull it off and got the crash. I got the file off, thanks. We can probably make this a low priority bug to fail gracefully on access denied... SVN commit 1217788 by kossebau: fixed: crashed if the file to export to could not be opened BUG: 264581 FIXED-IN: 0.6.1 M +1 -2 branches/KDE/4.5/kdeutils/okteta/libs/kasten/core/io/filesystem/abstractfilesystemexportjob_p.cpp M +1 -2 branches/KDE/4.6/kdesdk/okteta/libs/kasten/core/io/filesystem/abstractfilesystemexportjob_p.cpp M +1 -2 trunk/KDE/kdesdk/okteta/libs/kasten/core/io/filesystem/abstractfilesystemexportjob_p.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1217788 (In reply to comment #2) > Hah! I was going to add this info this morning. Yes, I didn't have rights. It > worked when I moved to a location with rights, Good, thanks for confirming. > but it was late, and I had lost > data not backed up, so I had done a dd of the drive and sure enough the file > was there in the dd dump even though it was technically deleted, so I was > trying to pull it off and got the crash. Oh, that drive was not too big, was it? Because Okteta still loads the whole file into working memory... But still nice to know you could help yourself with Okteta :) > We can probably make this a low priority bug to fail gracefully on access > denied... Not needed, does now :) (as intended already before, but seems I did not proper complete some refactoring) |