Notice: Trying to access array offset on value of type bool in /srv/www/vhosts/openpandora.org/domains/bugs.openpandora.org/httpdocs/scripts/details.php on line 649 FS#311 : [PATCH] Thunar configurable trash

OpenPandora Main OS

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Core
  • Operating System Release 1 (Zaxxon)
  • Severity Medium
  • Reported Version SuperZaxxon Final 1.53
Attached to Project: OpenPandora Main OS
Opened by Urja Rannikko - 29.12.2012
Last edited by Stefan Nowak - 02.01.2013

FS#311 - [PATCH] Thunar configurable trash

Not my work, but since I think my reply to ED on the forums will get buried I made this report. The post with patch: http://boards.openpandora.org/index.php/topic/11189-its-arrived-questions/?p=210363
Closed by  Stefan Nowak
02.01.2013 14:37
Reason for closing:  Fixed
Grazvydas commented on 29.12.2012 18:53
Added this patch with "no trash" as default. If anyone wants to try it and has SZ 1.52, try "System->Upgrade pandora OS" or "opkg update; opkg upgrade", then logout and log back in.
Admin
Stefan Nowak commented on 02.01.2013 00:50
Not sure wether this is really completely fixed! It "feels" ok, but nevertheless some unnecessary copy instead of move operations seem to happen (as a progress bar and loooong LED flashes indicate!). See my report below (file attachment still does not work in the issue tracker). Also made a dmesg of that session, but contained nothing relevant. Timestamps earlier than when I started testing, but I have it ready, should it be of relevance. --- Report --- # This is to determine how the Trash works in Thunar # On SuperZaxxon Final 1.52 with the most recent patching as of 20130101. # By user porg for OpenPandora bug  FS#249  $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346216 120236 74% / devtmpfs 250132 220 249912 0% /dev tmpfs 40 0 40 0% /mnt/.splash none 250132 220 249912 0% /dev /dev/mmcblk1p1 15622176 14452792 1169384 93% /media/snpd /dev/mmcblk0p1 6165708 3217032 2948676 52% /media/snpa /dev/mmcblk0p2 1032184 688444 291320 70% /media/snpb tmpfs 250132 3036 247096 1% /var/volatile tmpfs 250132 4 250128 0% /dev/shm tmpfs 250132 0 250132 0% /media/ram ubi1:boot 6992 4332 2272 66% /boot # Note: To make this log shorter and better readable, # I erased all none-changing (=irrelevant) lines of df in all further call-ups, # and marked numbers which changed to their previous state with an asterisk "*". $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346216 120236 74% / /dev/mmcblk0p1 6165708 3217032 2948676 52% /media/snpa tmpfs 250132 3036 247096 1% /var/volatile $ dd if=/dev/zero of=/media/snpa/debug/50mb count=50 bs=1M 50+0 records in 50+0 records out 52428800 bytes (52 MB) copied, 0.863434 s, 60.7 MB/s $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346204* 120248 74% / /dev/mmcblk0p1 6165708 3268232* 2897476 53% /media/snpa tmpfs 250132 3044 247088 1% /var/volatile # Thunar > right-click file > Delete $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346204 120248 74% / /dev/mmcblk0p1 6165708 3217032* 2948676 52% /media/snpa tmpfs 250132 3044 247088 1% /var/volatile # The file was immediately deleted. Not kept in Trash for a final removal. Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346204 120248 74% / /dev/mmcblk0p1 6165708 3217032 2948676 52% /media/snpa tmpfs 250132 3044 247088 1% /var/volatile # Will try again. $ dd if=/dev/zero of=/media/snpa/debug/300mb count=300 bs=1M 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 22.6505 s, 13.9 MB/s $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 346204 120248 74% / /dev/mmcblk0p1 6165708 3524232* 2641476 57% /media/snpa tmpfs 250132 3044 247088 1% /var/volatile # Thunar > Drag'n'drop the file to trash. $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 357840* 108612 77% / /dev/mmcblk0p1 6165708 3217032* 2948676 52% /media/snpa tmpfs 250132 3044 247088 1% /var/volatile # Thunar > right-click file > Delete $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 352192* 114260 76% / /dev/mmcblk0p1 6165708 3217032 2948676 52% /media/snpa tmpfs 250132 3048 247084 1% /var/volatile $ dd if=/dev/zero of=/media/snpa/debug/1000mb count=1000 bs=1M 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 90.2944 s, 11.6 MB/s $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 352192 114260 76% / /dev/mmcblk0p1 6165708 4241032* 1924676 69% /media/snpa tmpfs 250132 3048 247084 1% /var/volatile # Thunar > right-click file > Delete # Tells me this will be permanent. # Very likely told my so on my first attempt too, but I may didn't notice. $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 352192 114260 76% / /dev/mmcblk0p1 6165708 3217032* 2948676 52% /media/snpa tmpfs 250132 3048 247084 1% /var/volatile # Now I will create a file larger than NAND and will move it to the trash. # Should work if it sends the file to a per-filesystem-trash (on the SD). # Should fail if it sends it to boot-medium-trash (=NAND). $ dd if=/dev/zero of=/media/snpa/debug/1001mb count=1001 bs=1M 1001+0 records in 1001+0 records out 1049624576 bytes (1.0 GB) copied, 93.3381 s, 11.2 MB/s $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 352196* 114256 76% / /dev/mmcblk0p1 6165708 4242056* 1923652 69% /media/snpa tmpfs 250132 3048 247084 1% /var/volatile # Thunar > Drag'n'drop the file to trash. # This seems indeed a byte-by-byte copy process rather than of a move operation... # Dialogue with progress bar is shown and SD-LED flashes accordingly. # I wonder where it is moved to... df will reveal it to us hopefully. $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 387476* 78976 83% / /dev/mmcblk0p1 6165708 3217032* 2948676 52% /media/snpa tmpfs 250132 3052* 247080 1% /var/volatile # Thunar command > Empty trash # Took about 4 seconds. Quite quick, but still long. # A mere unlinking operation should just take milliseconds... $ df Filesystem 1K-blocks Used Available Use% Mounted on ubi0:rootfs 466452 368644* 97808 79% / /dev/mmcblk0p1 6165708 3217032 2948676 52% /media/snpa tmpfs 250132 3052 247080 1% /var/volatile # End of report.
Admin
Stefan Nowak commented on 02.01.2013 01:04
1) I just realized that this is a duplicate of my bug FS#250, which described the problem more in detail. Glad that it received a solution. 2) This bastard of an issue tracker can still not attach files and it removes all whitespaces in comments. My log file is barely readable that way! As an intermediary solution I created a new thread in the developer section of the board, and posted the files there: http://boards.openpandora.org/index.php/topic/11340-bug-file-browser-thunar-trashing-file-crosses-filesystem-boundaries/
Joel Makarov commented on 02.01.2013 01:10
It doesn't remove the white space it just renders text as HTML which ignores it. The emailed copy of your report was perfectly readable. Does anyone know if html tags can be included in comments?
Admin
Stefan Nowak commented on 02.01.2013 02:13
neelix: Thanks for that info, which I would have never noticed, as the notification is not send to the poster himself. Nevertheless the bugtracker's lack of attachments and proper whitespace display of comments (via tequniques such as HTML DIV or proper monospace CSS styles) is unacceptable.
Grazvydas commented on 02.01.2013 12:38
I'll close this one as the patch has been applied and confirmed to work. As for problems with bugtracker itself, you can create separate bug with proper title.
Admin
Stefan Nowak commented on 02.01.2013 13:56
I already did so on 2012-01-26 in  FS#271  But for 1 year no-one did anything about it! For that and other unsatisfying aspects of this bug tracker, I prefer bug-reports/feature-suggestions over at the boards. Raising attention and start a fruitful conversation works far better on the boards than here in my experience. The bug tracker seems to be used for mere code discussion of already known/established issues, but not for discovering new issues and their management/coordination.
Grazvydas commented on 02.01.2013 14:07
Hmm why reopen this bug? The bugtracked is only administrated by ED, you can't really expect him to do everything..
Admin
Stefan Nowak commented on 02.01.2013 14:36
I reopened only to resolve that meta issue. Closing now. Hopefully some-one cares for the bugtracker.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing