porg
Active Member
Last edited by a moderator:
Bug: File Browser Thunar - Trashing file crosses filesystem boundaries
- Thread starter porg
- Start date
That's nothing new, but that's something the XFCE-Team wants like that and doesn't fix.
urjaman already posted a patch last week that lets you disable the trash, it's just not yet been added to the OS.
urjaman already posted a patch last week that lets you disable the trash, it's just not yet been added to the OS.
porg
Active Member
@EvilDragon: You read too superficial: I am responding already to that patch from urjaman, which was pushed to the mainline by notaz, which I tested!
The problem is that the bug tracker still supports no file attachments nor whitespace in comments, therefore I posted here as an auxiliary space.
The problem is that the bug tracker still supports no file attachments nor whitespace in comments, therefore I posted here as an auxiliary space.
urjaman
"I Know. We're going for a ride."
And you read my solution too superficially. If you still have a trashing on delete you have not upgraded your OS or there is some config error (or old thunar running, reboot to be sure). The fix was to disable Trash. It should always warn that you're about to permanently delete. Your extremely-well compressible file fit on the nand because it was just zeroes and we have fs compression.
You can check that you have new thunar (and whether trash should be enabled or disabled) by going Edit->Preferences then on Advanced tab there should be an unchecked box named "Move items to Trash when on delete."
Note: Post Edited.
You can check that you have new thunar (and whether trash should be enabled or disabled) by going Edit->Preferences then on Advanced tab there should be an unchecked box named "Move items to Trash when on delete."
Note: Post Edited.
Last edited by a moderator:
Neelix
Insecticidal Maniac
I can confirm that trash still exists in the tree view on the left in the new version. (though it no longer appears an option in the right-click menu.
- Neelix
urjaman
"I Know. We're going for a ride."
I edited the text to reflect that yeah Trash exists so that stuff in there wont just disappear / you can empty it, etc. But the default action is to delete. For me it actually appears only in the Go menu...
Last edited by a moderator:
porg
Active Member
I upgraded the OS, then rebooted, then did my test.
My test report indicates exactly what I did in the commented lines ("#…").
"Right click > Delete" instantly deleted the file (ok for my personal taste, but moving to trash would be fine for majority I guess) and warns about it correctly (only the first time I did not notice it, but it surely happened).
Drag a file and drop it to the trash did copy, not move.
And thanks for explaining that filesystem-compression played a role in the test!
Explained why it fitted on the NAND, and also the delay (=data analysis), which felt too short for a complete copy operation, but too long for a mere move operation. So a trashing operation still crosses filesystems instead of putting it into a trash per filesystem. I know that i.e. Mac OS X does so. It keeps a Trash per Volume (=Mac term for disk partition). Therefore trashing a file is instant, just a filesystem operation, no data copied, and trashed files from different connected Volumes show as "one trash for the whole system" which in fact is just a display aggregation of all Trash-es from all Volumes.
Would try /dev/random for another test.
Or I can spare myself the tests, and explain what should happen in which scenario by design.
Would appreciate this!!! Thanks, porg
My test report indicates exactly what I did in the commented lines ("#…").
"Right click > Delete" instantly deleted the file (ok for my personal taste, but moving to trash would be fine for majority I guess) and warns about it correctly (only the first time I did not notice it, but it surely happened).
Drag a file and drop it to the trash did copy, not move.
And thanks for explaining that filesystem-compression played a role in the test!
Explained why it fitted on the NAND, and also the delay (=data analysis), which felt too short for a complete copy operation, but too long for a mere move operation. So a trashing operation still crosses filesystems instead of putting it into a trash per filesystem. I know that i.e. Mac OS X does so. It keeps a Trash per Volume (=Mac term for disk partition). Therefore trashing a file is instant, just a filesystem operation, no data copied, and trashed files from different connected Volumes show as "one trash for the whole system" which in fact is just a display aggregation of all Trash-es from all Volumes.
Would try /dev/random for another test.
Or I can spare myself the tests, and explain what should happen in which scenario by design.
Would appreciate this!!! Thanks, porg
Last edited by a moderator:
urjaman
"I Know. We're going for a ride."
You can/should expect to find that "trash" is still on the nand, but the default menus should have no other way to Trash (meaning move to trash) stuff than to open two thunar windows and open trash in one and drag to it from the another (atleast I dont find one...). The point of fix/workaround was mostly to make it so that people dont accidentally move stuff to NAND... And this was originally a personal fix that ED requested me to share, so I'm not claiming that work is done regarding this.
porg
Active Member
urjaman, thanks for your info!
Would be fine if trash-per-filesystem gets implemented one day,
but for now your provided solution is the best! Thanks!
Would be fine if trash-per-filesystem gets implemented one day,
but for now your provided solution is the best! Thanks!
- Default delete action -> immediate with prior warning.
- Should one require to not immediately delete, but move "stuff out of way", then drag n drop stuff to Trash for later final deletion.