Re: [ql-users] Q-Trans Trash can

[James Hunkins]

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