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
