I am going to be updating the Trash roxapp soon (hopefully next week).
But I want to start a more general discussion about its future.
Please respond with either your opinion of how the Trash should work (in terms of what the user sees), and/or specific discussion of the details of implementing it.

------------------------

Personally, I would like to see a trash that places deleted items in a .trash folder in the top directory of the filesystem they come from - similar to the way the Windows recycle bin works. One specific benefit of this will be that you can trash a large item from some mounted partition, and it won't be copied into your small pup_save file, filling up space. It will also avoid potential problems caused when you trash an item but there ISN'T enough space, and when you try to restore a file that came from a filesystem that isn't currently mounted. On a multi-user system it would also allow you to restore things someone else has deleted.
Ideally I guess anything deleted from inside a user's home directory should be sent to ~/.trash rather than than /.trash as well.

I think the implementation of this might be a bit beyond me - in particular I have no idea how to determine where the top of the filesystem the deleted item came from is. Also, we would have to do away with any symlinks (e.g. for .DirIcon) in the appdirs of the trashed items, to allow for Windows filesystems. (or just be happy with not having an icon on windows filesystems).

And how would we centralise it? We could send anything trashed from inside ~ to ~/.trash, and also put symlinks there to anything else the user trashes. (We couldn't put the actual appdirs there, and just put the actual deleted items elsewhere, as the whole point in the appdirs is to cope with deleting files with the same name). But would this arrangement be too confusing on a multi-user system, because you would see everything you trashed in ~/.trash, but if you go to /mnt/hdb1/.trash, you will see things that don't show up in ~/.trash, because someone else deleted them?

Also, should we have some sort of check (if that is possible) for read-only filesystems, so you can't accidentally send something to the trash that doesn't actually get deleted after all? (Actually, this might not be a problem - I can't remember how the code works, and I haven't tested to see what happens at the moment).

Well when I wrote the trash application originally, I intentionally did not put the trashed item in the drive that it came from. Mac OSX does this and it makes invisible .trash files on all your external drives, even your USB thumb drives. I have always found this annoying. It could be done pretty easily though. Although you could leave it the way it is and just check if there is not enough room in your pup_save file. It would be easy to notify the user if the trashed item was too large or if it was on an external drive. Read only file systems could be an issue if you wanted the trashed items on the original drive, but I have an even greater concern. What if the drive is formated as NTFS? Some Puppys can write to NTFS drives, but if the NTFS drive isn't in the best of shape it could cause data loss. My vote would be to leave things the way they are but check to see if the trashed item is large or on an external drive. If it is, then offer to just delete the item and not put it in the trash bin. I should update the Trash app to check for NTFS drives anyways. I was planning on updating the looks of the trash soon. It was going to get a FLTK interface. I think that FLTK can look much nicer than xmessage.

OK, if you are planning to update it, here are the facts to be aware of (you probably know most of it already though)
-I updated it a while ago to handle paths with spaces, and to add some enhancements.
-Someone else over at Rox also fixed the spaces issue (I wish I'd known that before!). They then fixed a number of other bugs apparently (there is a proper changelog), added some features, made it Freedesktop compliant and ported it to some GTK gui. One important result of their changes is that you can trash files/folders called .DirIcon and AppRun and whatever the other file is that appdirs need, without losing them forever. I was going to fix this, so I'm glad I found out.
-I started (but don't have time to finish until sometime after easter) backporting their version to work with xmessage and .trash rather than .Trash (so that it is backwards compatible with Puppy's trash), and adding my earlier feature enhancements in. I also intend to make clicking on a trashed item bring up the information window, which will have a button to open the file (I did have clicking open the file).
-Does Dingo have FLTK? There are so few FLTK apps around that if you use FLTK you should really keep the capability of using something else if necessary. Or will it be statically linked, and will that solve the problem? Also, Puppy has so much GTK that gtkdialog or something would fit in better. Maybe we could introduce to Puppy the gui that the guy over at ROX uses. But I think it was quite large by Puppy standards.

I worked with the guys over at Rox for a while, but I got busy changing jobs and what-not. I'll have to check back and see what they came up with. I would just use murgaLua for the FLTK interface. Just test for murgaLua at the begining of the script. If it is there than use it. Otherwise use xmessage or gtkdialog.

I've never used the Trash Roxapp and probably never will unless I get really bored, so please excuse any ignorance on my part. Not that I have anything against it. I've just learned the hard way since leaving 'doze that once I delete something it's gone, and do not want to unlearn that and get sloppy and also have to worry about emptying trash and such...

Quote:

Also, we would have to do away with any symlinks (e.g. for .DirIcon) in the appdirs of the trashed items, to allow for Windows filesystems. (or just be happy with not having an icon on windows filesystems).

Why give up the icon? Just name the image itself .DirIcon and not have any symlinks in the first place.

As far as determining the root of the filesystem a file comes from, that shouldn't be too hard. Running mount returns a list of all mounted filesystems and where they're at. Assuming you know the file's full path, you can do some string processing to figure out where its root is.

Quote:

And how would we centralise it?

I'm not familiar with how it works. I do know that you can use mount to see all the mount points, then do a check to see which of them have .trash directories. Then you could symlink the trash directories or their contents or do whatever else you feel inclined to do. I think something like "trash_from_hda1/", "trash_from_hda2", etc. would make sense, though it's a little long winded.

The idea of placing the trash on the drive it came from has the advantage of being pretty fast (moving files within a partition doesn't really need any actual data transfer, unlike across partitions)._________________Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib

Okay I have been thinking about this and playing with some of my USB flash drives that have trash directories from Mac OSX. Here is what I'm thinking. When a user sends something to the trash, first check for any issues such as read only partitions/drives or NTFS formated partitions/drives. If it is such a drive, show the user a message letting them know the issue and exit. This is something that should be done anyways. When something is sent to the trash from inside the pup_save file then put it in $HOME/.Trash. If the user was root (such as in Puppy) then it would be /root/.Trash. If the user was Bob then the path would be /Bob/.Trash. If the trashed item is from another area, put it in the top of the partition for that drive. For instance /mnt/sda1/.Trash. Here's the catch, on boot and anytime a new partition is mounted or un-mounted, the trash icon would have to be updated to see if there was anything in the hidden trash folders. This would be easy to add to the new auto-mount script that I am writing. One thing that really bugs me about the Mac OSX trash is the emptying of the trash with other drives mounted. If you have a drive mounted with things in it's hidden trash folder, emptying the trash deletes all the files in all the hidden trash folders on all the drives. Maybe a separate menu option to empty the trash for each partition would be good? One fun feature would be to use and show the trash folders that may already be created by Mac OSX. If done right, Mac OSX would use the trash folders created by Puppy.

Not quite sure why you are improving what works?
Are there any security issues?
Could you shred the data? (overwrite with 0 & 1 several times)

Do you intend animating the icon?
Maybe a record of how much is in the trash?
Store trash as gmail option?_________________Puppy WIKILast edited by Lobster on Thu 04 Sep 2008, 02:35; edited 1 time in total

You can use the stat command to find out what physical drive a file or folder ison.

Not too long ago I wrote a Rox AppDir called RecycleBin which lets you throw itmes away and still be able to put them back where they were originally. I also had thought about implementing separate trash cans for each drive at least as an option. Other pressing matters stopped the work on it for awhile.

Why give up the icon? Just name the image itself .DirIcon and not have any symlinks in the first place. Wink

Yes, but if we are ultra keen on saving space, then a symlink is better, and it's not like there's any real need for the icon. Also, then the icon could be changed with themes
Although I think Nathan was talking about rewriting the trash to actually use an icon that matches the mime type of the file... which would be cool, but sounds horrendously difficult.

Quote:

I've just learned the hard way since leaving 'doze that once I delete something it's gone,

I just avoided the trash until I sat down to figure out why it didn't work, and realised that the reason was simply that I usually had spaces in the paths. So I fixed that, and now Lobster says

Quote:

Cool seems to just work

Well, somebody who didn't use spaces would have said that before, but they would have been wrong - for me it certainly did not work.
At the moment if you unwittingly trash something called .DirIcon or AppRun or AppInfo.xml or whatever the other thing is, then it is GONE FOREVER.
So we will get the fix for that. And apparently the guy at ROX has fixed other bugs - I didn't notice any others, but hey, if they're fixed, that's great.
Then it will almost "just work". Except for the very real issue of trashing something big from elsewhere, and filling up your pupsave. So I think we should at least do a check to prevent that...

No - I don't really know or care about security issues. And shredding data is a completely different task from what the Trash does, so if you want an app for that, I think it should be separate (I guess it could be on the item's right-click menu - but how many people would ever use it? Is there a utility in Puppy for shredding things?).
No - I don't care for animated icons.

Quote:

Maybe a record of how much is in the trash?

That is a good idea - do you want the icon do indicate this? That would be meaningless if we do what I want and have .trash directories on every partition. But if we do it the way Dan suggests, detecting Trash directories, (which is compulsory if we want to be Freedesktop compliant) then I think we could put an option on the right click menu to show us a table for this.

Quote:

One fun feature would be to use and show the trash folders that may already be created by Mac OSX.

And what about Gnome and KDE etc? I ended up with things in trash on my flash drive in Ubuntu, but I'm not sure whether it was Gnome or KDE that did it. I wonder if the Mac trash is anything remotely near being freedesktop compliant. I just had a look at the Freedesktop specification, and there are lots of random checks we need to make to be fully compliant. Some I don't understand, but others, like checking that e.g. /mnt/hdb3/.Trash isn't a symlink, are very helpful
If we want to be compatible, I guess we should use .Trash rather than porting it back to .trash
We could just have Puppy rename /root/.trash in an upgrade, or (safer) the trash roxapp could move anything in .trash to .Trash when you click on it.

Quote:

Freedesktop spec:If the directory exists and passes the checks, a subdirectory of the $topdir/.Trash directory is to be used as the user's trash directory for this partition/device. The name of this subdirectory is the numeric identifier of the current user ($topdir/.Trash/$uid). When trashing a file, if this directory does not exist for the current user, the implementation MUST immediately create it, without any warnings or delays for the user.
When trashing a file, if an $topdir/.Trash-$uid directory does not exist, the implementation MUST immediately create it, without any warnings or delays for the user.

I don't like that part of the spec - it is so cumbersome it makes me want to ignore the spec and throw compatibility out the window. If you trash something from a filesystem that other people have access to, surely it is best to give them access to the trash too?

Quote:

Freedesktop spec:When preparing a list of all trashed files (i.e. to show to the user), an implementation also MUST check for .Trash in all top directories that are known to it.

That is worse than the icon problem you mention - I can't think how it would even be feasible to display all files with our ROXapp approach. I realised another problem with my idea of symlinking anything you delete elsewhere into ~/.Trash - if you go to /mnt/sda1/.Trash or whatever and delete it, you will have dead symlinks. Maybe we would just have to put symlinks in ~.Trash to all the .Trash folders.

Quote:

Maybe a separate menu option to empty the trash for each partition would be good?

Definitely something like that. But we could just have a menu option to show information on the trash directories, and it could list them, with their sizes, and buttons to empty them. HEY - we could have buttons here to open each trash directory, instead of trying to have one window that shows all trashed files. And we could even open this window when clicking on the roxapp. I think that would work quite well.

Reading this carefully, it seems that even though the guy at Rox thinks he is freedesktop compliant, he really isn't. He has a directory for each deleted item inside .Trash, with info and files folders in each one of these directories. I'm inclined to say we stick with this approach, and don't have all that rubbish about $uid directories. Because actually, he isn't freedesktop compliant anyway, because the mechanism for restoring files is built into the roxapps, so we can't restore files that were trashed by something else, because they aren't in roxapps.

Quote:

Freedesktop spec:The system SHOULD only support absolute pathnames in the “home trash” directory, not in the directories under $topdir.

This is a good call.

If anyone wants to read it, I could only find the freedesktop spec at http://web.archive.org/web/20070815003029/http://www.ramendik.ru/docs/trashspec.html

So I think we have 3 choices:
1-sticking with essentially what we have, but with the refinements I will do, and anything anyone else does
2-moving to a fully freedesktop compliant system, which we could not really do with a Roxapp based system - I wonder if there is anything lightweight available already.
3-rewriting our roxapp based system as Dan and I have described, to support a similar thing to what the freedesktop people call $topdir trash directories.

I definitely prefer the third option, but that is probably because I don't anticipate ever using anything other than Rox. If we did 1 or 3, we would also have to choose whether to stay with .trash or move to .Trash, but since there is no real compatibility with other systems, I can't see the benefit of changing.
Personally, I think anyone using Puppy who is switching between using this and using a Gnome trash or something, is probably smart enough to handle both systems. The only real reason for wanting a freedesktop compatible system is if you bring a flash drive home from your Ubuntu computer at work or something like that.

OK, I found it easier to start with my version and merge select features from Achaw's version, rather than the other way around.

-I took the version from Dingo and fixed the bugs introduced by Barry's modifications for Dingo (it didn't play the sound, or restore the "empty" icon if you deleted or restored the last item in the trash).
-I then added some of Achaw's features and bugfixes, most notably putting the trashed item in a "Files" subdirectory, so that you can safely trash files called .DirIcon, AppRun or AppInfo.xml, and restoring a desktop icon (if there was one originally).
Because I started with the code from Dingo, people with older Puppies will need to either edit the scripts, or move/link their existing icons (from inside the Trash roxapp) to /usr/local/lib/X11/pixmaps/trashcan_empty48.png and /usr/local/lib/X11/pixmaps/trashcan_full48.png
-I didn't add the "restore all" feature as I don't think it is useful, but it would be easy to add if people want it.
-I commented out the "quickly empty trash" entry in AppInfo.xml, as I think that option is dangerous, but it will still work if you uncomment it.
-I think it will now work in a multiuser system, but haven't tested that.

---------------------------------------------------
HELP WANTED - SOMEONE WITH A LITTLE KNOWLEDGE AND 5-30 MINUTES...
1. I simplified Achaw's feature of writing information about the trashed item to an "info" file, so that instead of parsing the "info" file like he did, it just displays the entire contents of the file, so that it is even easier to add additional information. I would like to add the size of the trashed item to this file, I just don't know how to find it.
I don't know what other information people would find useful - maybe permissions? Change/modify/Access times? The names of links to this item that we removed from the pinboard (these are stored in the "shortcut" file so it would be easy to do)?
This information is written around line 101 of AppRun.

---------------------------------------------------
OTHER IMPROVEMENTS THAT WOULD BE NICE
2. Action buttons (delete this item, restore this item) in the info window.
If we added these it would make a lot of sense to bring up the info window on double click, instead of opening the trashed item with whatever Rox opens it with, as I have it doing now. I think you could still do this just with xmessage, but i don't know how to get at the exit codes.

3. A check for space in the filesystem that contains the trash folder, when a file from elsewhere is sent to the trash. Also, a message to confirm if you want to delete a large file (I don't know - 5, 10, 20 MB?) from outside this filesystem would also be useful.

4. Maybe we should consolidate the code a little - at the moment the original file's path is stored in two places - in the info file and in the apprun file itself. If we took it out of the AppRun file, maybe this file could be a symlink just like .DirIcon and AppInfo.xml?

5. If you send several items at once to the trash, it would be nice to see them in the trash together (i.e. as one trashed item) - this might be a little tricky to do.

6. We could fix it so that it restores all shortcuts on the pinboard, not just one, but I don't think this is that important.

7. What would be very useful is another option on the main trash right-click menu, that will generate some sort of list of files in the trash, with other information, such as size, deletion date, and file extension, (probably by reading the info files). This list could be used to sort files by things like extension and size, which isn't possible currently (maybe in a spreadsheet would be easiest).

OK, I figured out how to do number 2 (I'll upload tomorrow after I test a little more carefully).
For the desktop links in number 1 I am just putting a yes or no, rather than names.
I would really like to know a command to get a sensible printout of the size of a file or directory, and I am quite keen on having the permissions and times as well._________________Classic Puppy quotes
-
root: n. the superuser or administrator account that has complete control over everything in the machine. Running as root is a taonga of Puppy Linux users.

`-c'
`--total'
Print a grand total of all arguments after all arguments have been
processed. This can be used to find out the total disk usage of a
given set of files or directories.

`-D'
`--dereference-args'
Dereference symbolic links that are command line arguments. Does
not affect other symbolic links. This is helpful for finding out
the disk usage of directories, such as `/usr/tmp', which are often
symbolic links.

`-h'
`--human-readable'
Append a size letter such as `M' for megabytes to each size.
Powers of 1024 are used, not 1000; `M' stands for 1,048,576 bytes.
Use the `-H' or `--si' option if you prefer powers of 1000.

`-H'
`--si'
Append a size letter such as `M' for megabytes to each size. (SI
is the International System of Units, which defines these letters
as prefixes.) Powers of 1000 are used, not 1024; `M' stands for
1,000,000 bytes. Use the `-h' or `--human-readable' option if you
prefer powers of 1024.

`-l'
`--count-links'
Count the size of all files, even if they have appeared already
(as a hard link).

`-L'
`--dereference'
Dereference symbolic links (show the disk space used by the file
or directory that the link points to instead of the space used by
the link).

`--max-depth=DEPTH'
Show the total for each directory (and file if -all) that is at
most MAX_DEPTH levels down from the root of the hierarchy. The
root is at level 0, so `du --max-depth=0' is equivalent to `du -s'.

`-X FILE'
`--exclude-from=FILE'
Like `--exclude', except take the patterns to exclude from FILE,
one per line. If FILE is `-', take the patterns from standard
input.

On BSD systems, `du' reports sizes that are half the correct values
for files that are NFS-mounted from HP-UX systems. On HP-UX systems,
it reports sizes that are twice the correct values for files that are
NFS-mounted from BSD systems. This is due to a flaw in HP-UX; it also
affects the HP-UX `du' program.

OK, I have finished with it now. I added some more information in the info window and added action buttons for everything.
I changed it so that the info window is shown when you click on the trash.
I fixed a bug in restoring pinboard shortcuts to files with spaces in the name.
I changed it so that when you restore an item you can choose to cancel, or to overwrite or trash an existing file/folder with the same name.
I made it fix the trash icon when you click on it if it showing as full when it is actually empty.
I might have added other features, but I can't recall

The only issue is that what the info window shows for "Extension" is silly if the file doesn't have an extension. But there isn't really a good way around this.

1. Why bother trying to list the file extension, you have the full filename already.

2. The du -h listing with sizes is great. I think it would be better if you used the full listing rather than cutting off the file names._________________Will
contribute: community website, screenshots, puplets, wiki, rss

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum