Deleted files on shares going to ".Trash-1000"?

[jbmia]

... instead of to greyhole attic... Am I missing something here... I'm having fits trying to delete some legacy files on my test box.. The files keep getting put into either ".Trash-1000" or ".Trash-500" folders with their associated sub-folders and don't seem to be going to the .gh attic folders on the drives?

I've tried deleting these folders, sub-folders, and even individual files without success... I'm hitting Samba mounts when trying to delete them (e.g., /mnt/samba/pictures/.Trash-1000/files/...) using "rm -rf "file" or "folder" name... if I try to delete files, they just don't delete.. if I try to delete folders, it says they're not empty... I've changed ownership and updated permissions etc...

Searches on issues trying to delete .Trash-1000 files go way back in Linux, but I see nothing here on Amahi with or without Greyhole. How does this trash file logic play with the greyhole attic process? How is this supposed to work?

Right now, I delete a file in a share and it goes to .Trash-1000... and the hard drive space is not being recovered... How are these supposed to get to the attic so I can just empty it?

I have a production box as well that I recently migrated to thats been stable for a few weeks that I've done no file management on since the conversion. I just tried to delete a single file in one of my shares from an ubuntu machine via ssh to the /mnt/samba/share_name samba mount on that machine... With no prompting, it is deleted immediately and dropped into a ".Trash-1000" folder behind the scenes. Thinking this might be a Samba mount thing, I browsed to the share directly by navigating via Places/Network/HDA/share_name and deleted a file in the same share folder. System prompted that item cannot be moved to Trash and must be deleted immediately. I confirm and it's deleted. File is not moved to the .Trash-1000. Not sure if it's deleted outright or moved to the attic as greyhole --stats is just reporting in gbs and file size is small.. but there's definitely something different going on depending on how you access and manage these files...

This raises some questions... #1 seems like file should not be deleted from the /mnt/samba/share_name path.. else you end up with these .Trash-1000 folders and a circular pain in the rear trying to delete them... #2 How do I delete these .Trash-1000 folders and their content now that I do have them?

Thanks for any assistance.

jbmia

[gboudreau]

I'm not sure exactly how you delete a file so that it ends up in a .Trash-xxx folder.
Is it from the Amahi server itself, or from a remote server ?
I'd like to see a screenshot of you deleting a file (just before hitting the Del key).

I'm pretty sure those .Trash-xxx folders are created by Gnome.
If it creates them, it's because it thinks those files are on a normal hard drive, not on a share.

[ccondrup]

I've been seeing .Trash-500 folders from time to time so I decided to do some testing, using: hda-greyhole-0.9.16-1.i386. Learning Linux as I go, so I need the visual help of X/Gnome. I login either via VNC or operate directly on the box, and often need to access the shares while on the HDA, so I've followed the wiki: Mount shares locally.

Method 1: Delete a file from locally mounted share using terminal:
Using pastebin to keep the post readable: http://pastie.org/2748026 In short: Everything looks fine.


Method 2: Delete a file from locally mounted share using Nautilus/GUI:
1. Add a testfile named "asasas.txt" to the share "Install" which is pooled and set to 1 copy. Output: http://pastie.org/2748030 - All good.
2. Now open Nautilus (logged in as user cc) and point it to /mnt/samba/Install/. You requested a screenshot at this point, here it is: https://i.minus.com/ibeVnYhAbx52rB.png
3. Right click file "asasas.txt" and select "Move to trash".
4. File disappears from this folder but does not go in the "Greyhole Trash"-share. Greyhole log upon deleting file shows a lot of weird stuff happening: http://pastie.org/2747962
5. Now update the db for "locate" command and use it to find where the deleted file has ended up: http://pastie.org/2747983 - There we go, the .Trash-500 folders have been created and even distributed in the pool.

So..
Is this a bug somewhere, is there anything we can do about it or should we just avoid using GUI to delete/move from shares when logged onto the GH box? Contact me on IRC if you need quick info/testing, nick: supergreg.

[gboudreau]

Greyhole acts as expected in the case you detailed.

When you deleted the file in Nautilus, instead of really deleting the file, it chose to move it to a trash folder. Greyhole correctly logged the operations Nautilus did when that happened, and correctly handled them.
From what I know of Nautilus, this should not happen on remotely mounted filesystems, even if those mounts are really from a local Samba server, and not really remote.

Your options:
- empty the Nautilus trash once you're done deleting files. This will remove the files that it created in the .Trash-XYZ folders.
- disable the Trash option in Nautilus
- don't use Nautilus to delete files

[ccondrup]

Gotcha, thanks for the follow-up.