Version: Version 1.0.99, KDE 4.00.84 (KDE 4.0.84 (KDE 4.1 >= 20080625) (using Devel) Installed from: Compiled sources OS: Linux I just tried to delete a 8GB file with dolphin and got reported that the file does not exist, even if dolphin shows the file perfectly. I traced down that there seems to be a problem with files bigger than 2048 MB, due 2047 and bellow seems to work fine. This problem seems to be always reproducable. How to reproduce: 1. Run "dd if=/dev/urandom of=2GiB_file bs=1M count=2048" to generate a 2 GB file 2. Run "dd if=/dev/urandom of=smallerGiB_file bs=1M count=2047" to create a file with one MB less 3. Try to move the 2047 MB file to trash. 4. Try to move the 2048 MB file to trash. Dolphin claims that the 2048 MB file or folder does not exist. I guess that the file is to big to be moved to the trash bin. However the user should be informed about it, instead of claiming that the file does not exist. Pressing shift before selecting move to trash deletes the file without a problem. The files was generated on a ext3 file system (no vfat or something like that).
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