Far too complex for what is a fairly simple compiled basic piece of code as outlined. No chance whatsoever of this being done - Q-Trans has no date handling routines or file stats facilities anyway, plus the simple minded approach means the Q-Trash (or whatever you call it) can be manipulated by any file handler.
Dilwyn ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 19, 2003 3:52 PM Subject: Re: [ql-users] Q-Trans Trash can > In a message dated 19/01/03 15:12:05 GMT Standard Time, > [EMAIL PROTECTED] writes: > > > > 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. > > > > Phew - there were some terrible problems with that Trashcan, which made me > abandon it in the end!! > > > 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: > > > > <<Cut>> > > > > Dilwyn, there seems to be a much better option. The best trashcan would be > able to store various versions of the same file, sorted by original date > order, then you could choose which one to restore. > > I would suggest that either you need an index file and create your own > shortened filenames to store these in the directory, or possibly easier, add > some sort of header to each file to identify the details. > > You should store: > 1) original directory path > 2) original file name > 3) date file was created > 4) date file was deleted > 5) Expiry date (? Suggestion - automatically clear all files in the trashcan > after 60 days or so - user defined) > > -- > Rich Mellor > RWAP Software > 35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH > TEL: 01977 610509 > http://hometown.aol.co.uk/rwapsoftware >
