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

[James Hunkins]

I actually date stamp backup copies of the desktop files in QDT, using 'C' system calls that tap into QDOS stuff. It is actually quite easy (once I looked it up and tried it that is). Using the date that the file was trashed would work but what if a person throws the same file name 2 or more times in a day; perhaps append a letter to the end of the day if the file is already in the trash?

I am also thinking that you may be able to easily maintain the original file write date when you move it. I seem to recall a way of doing it but the details are not coming to mind. This would be seen for example in the files application. Definitely not a requirement if you date stamp it as you mentioned but a nice thing instead.

jim

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