The MAC OS X trash capability keeps it simple. When it stores a file in the Trash, it simply moves it there, maintaining the original file creation date. If there is already a file with the same name, it appends a -n to the name, where 'n' is an incrementing number.
You can't find out where the file came from. The only consolation that they did is you can undo a single Trash 'move' to the source but only a single one.
Since the highest use for a trash can seems to be to undo very recent mistakes (the 'Ah S...' scenario) and not to be used for a real recovery, I would agree with Dilwyn that it should be kept simple.
Some Unix users may be more familiar with a much more complex recovery but it is actually a separate program that maintains a 'mirror' of everything on a drive and not really a trash can. We won't even talk about disk space issues.
Not to mention, we all backup on a regular basis anyway, right?
Jim
On Monday, January 20, 2003, at 02:01 AM, Malcolm Lear wrote:
I would add a simple text file to the trash directory. Initially you
would only need to store the original path+filename and the trashed
filename (usually unchanged) on each line with a suitable separator.
Later more info could be added wilst maintaining backward compatibility.
I doubt that any system not using some form of index file would be of
much use.
Cheers
Malcolm
Dilwyn Jones wrote:
I've added a Trash-can facility to Q-Trans and would like some feedback on how it should work. Basically, it's a short one character length named folder on a specified drive (e.g. WIN1_*_) into which files are moved rather than being deleted as such, so that a degree of restoration of 'deleted' files is possible. Note: it's not the same trashcan as Phil Borman implemented in later Qubides. The feedback I'd like is on the name convention for files in the trashcan. Since it's basically a very primitive facility, equivalent to: REMark DELETE drive$&directory$&filename$ DELETE trashcan$&filename$ COPY drive$&directory$&filename$ TO trash$&filename$ Option 1 would be just as above, the "pure" filename is all you see in the trashcan, so it can be restored to anywhere and you don't see where it came from. Option 2 would copy the original path name and filename into the trashcan, so that you can see where the file came from and where it would be restored to, the snag being name lengths allowed by the QL filing systems. The longest allowable QL path length is 41 characters (36 character filename plus drive name length), so it would mean long names being truncated. Consider when you have a long path name such as WIN1_work_xchangefiles_docs_ (28 characters) and a filename like workfile_doc (12 characters) this comes to 40 characters in all, but copy it to a trashcan folder named win1_*_ and you'd get win1_*_win1_work_xchangefiles_docs_workfile_doc (47 characters in all) which would be truncated to win1_*_win1_work_xchangefiles_docs_workfi Option 3 would be similar to option 2 but only the directory name (not the drive name) is used, reducing the risk of truncated filenames. So while option 2 or 3 allows you to see where the file came from, they have a greater risk of truncated filenames. Option 1 doesn't store info int he filename about where the file came from, but doesn't have such a risk of truncated filenames. Option 4 would be to make the program configurable to allow any of the options, equivalent to this in BASIC in the way it would work: SELect ON option =1:dest_filename$ = filename$ =2:filename$=directory$&filename$ =3:filename$=drive$&directory$&filename$ END SELect filename$=trashcan$&filename$ IF LEN(filename$)>41 then filename$=filename$(1 to 41) Hope this makes sense! P.S. Finally solved the mysterious problem some people where having with the RENAME command, caused by a parameter coercion error in an MITEM command. -- Dilwyn Jones
