No objections whatsoever to your use of the Trash can concept. Just remember to mention that despite the name, it is definitely NOT the same as the Qubide Trashcan. (I couldn't think of a decent name other than Trash or Recycle!)
All for standardisation! The Trash system is now basically up and running, the program compiled OK, and the standard Trash is WIN1_*_ but the name can be up to 10 characters long to allow the Trash to be on a single digit network station if required (e.g. a cluster of QLs only one having a hard disk). The Trash is a 'one for all' solution, files from any drive are dumped into that one Trash can, with the option (configurable) of the files being named by just filename (option 1), directory name+filename (option 2), or drive+directory+filename (option 3). If you go for a different Trash on each drive, option 3 definitely not required! I'm looking at how feasible a 'delete files older than xxx days' option might be. It's likely it'll be a loose item in the Commands menu which only becomes active if that window is displaying the Trash. I'm not too sure how to handle file dates, I feel a small learning curve coming on! Basically, it'll work from whatever date the file was put into Trash. Main thing though is that it's kept simple. The file that goes into the Trash can really will be a last ditch disaster recovery file, no original dates stored, the only path info being the filename as copied. In that sense I'm disregarding the 'for it to be useful it has to do x and y clever things' requests which will involve creating extra bytes in the file or some form of index file stored in Trash. Trash is simply 'Move File Into A Directory Rather Than Delete' not a full recycle bin. -- Dilwyn Jones ----- Original Message ----- From: James Hunkins <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 19, 2003 9:25 PM Subject: Re: [ql-users] Q-Trans Trash can > > Dilwyn, > > What I have seen done is: > - if another copy of a file exists in the trashcan, rename the copy > being moved there (IE: _1, _2, _3). This doesn't require a date thing > but, using the date code on the file would be about the same thing). > > Also, if you don't mind, I would like to 'borrow' your trashcan concept > for QDT. I have this thing about standards - love them. Any > objections? > > Jim > > On Sunday, January 19, 2003, at 10:06 AM, Dilwyn Jones wrote: > > > > > 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 > >> > > > > > > >
