Summary: | Unable to trash files bigger than 2 GB | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Florian Sievert <FlorianSievert> |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | kdeinit konsole output |
Description
Florian Sievert
2008-06-30 23:13:09 UTC
I can confirm that this bug is happening to me also. KDE Version: 4.0.5 Using Kubuntu 8.04 KDE4 Remix Confirmed based on testing feedback. Changing the subject to "Unable to trash..." instead of "Unable to delete..." since moving a file to the Trash Can is what doesn't work, deleting does. I'll have a look. Was the file-to-be-trashed on the same partition as the trash dir (i.e. as $HOME, by default), or on another partition? I fixed a bug with trash directories on other partitions, but other than that, trashing both files works fine here; I cannot reproduce this bug with svn trunk r826995. Florian, since you're using svn trunk, can you update and retry? If it still fails, please provide me with the debug output from kio_trash (which can normally be found in ~/.xsession-errors, or in the terminal where you start kdeinit4). Created attachment 25784 [details]
kdeinit konsole output
Hi David, thanks for the fast response! The problem is still reproducable here. I just updated and compiled revision 827019. The file was on the same partition. I did a test putting the same file on another partition and there it wasn't even offered to trash the file (greyed out). I am currently in a hurry and will try this evening, if it would work with the 2047 MB file. A .xsession_error did not exist, however I upload a log file with the terminal output. The KDE session was started fresh and directly after the start I did try to delete the test file from the home (/home/kdedevel) folder of the users. Directly after that I tried to delete the second test file on another partition (/ftp). I guess Line 751 is the interesting one, where it fails to rename KURL. If I can provide any other informations, please let me know! Ah I know. This is on a 32 bit machine, right? I'm testing on a 64 bit machine so obviously it works there. I see. _FILE_OFFSET_BITS isn't set anymore, argh. SVN commit 827116 by dfaure: Move up the definition of _FILE_OFFSET_BITS so that it's also available for kio_trash, otherwise files bigger than 2GB cannot be trashed on 32 bit systems! I don't think it hurts to define it for all of kdebase/runtime, no need to set it in individual folders. CCMAIL: vladc6@yahoo.com, mueller@kde.org BUG: 165449 M +2 -0 CMakeLists.txt M +0 -2 kioslave/smb/CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=827116 Yes, it is a 32 bit system. I am confirming that the problem is fixed now. Git commit 0ec4b7b4128a9aa22530512bb87863e5d72ee2f2 by Alex Merry. Committed on 02/05/2014 at 15:53. Pushed by alexmerry into branch 'master'. Set _FILE_OFFSET_BITS=64 again when necessary This essentially reverts db553c810cbc3a446f90d4c962110d6262853cde. It turns out that (for better or worse) quite a few places access files without going through KFile, so it is worth making sure they can deal with files larger than 2Gb on 32-bit systems. Reviewed by: Harald Sitter <sitter@kde.org> M +20 -0 kde-modules/KDECompilerSettings.cmake http://commits.kde.org/extra-cmake-modules/0ec4b7b4128a9aa22530512bb87863e5d72ee2f2 |