Dilwyn,
if you wanted something really simple, set the 'backup' date of the file in
Trash to be the original 'update' date of the file before 'trashing'.
Similar, but totally different, to what I do in WinBack. (And you have the
source code !)
If you want, there are FSET_xxxx routines in Winback.bin (and source in
Winback.asm) that you are free to use and abuse. The one you'll want for the
above suggestion is FSET_update('file_name', date_as_number) where
date_as_number is simply the return from FILE_update or whatever.
Cheers,
Norman.
-------------------------------------
Norman Dunbar
Database/Unix administrator
Lynx Financial Systems Ltd.
mailto:[EMAIL PROTECTED]
Tel: 0113 289 6265
Fax: 0113 289 3146
URL: http://www.Lynx-FS.com
-------------------------------------
-----Original Message-----
From: James Hunkins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 5:44 AM
To: [EMAIL PROTECTED]
Subject: Re: [ql-users] Q-Trans Trash can
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
>>>>
>>>
>>>
>>>
>>
>
This email is intended only for the use of the addressees named above and
may be confidential or legally privileged. If you are not an addressee you
must not read it and must not use any information contained in it, nor copy
it, nor inform any person other than Lynx Financial Systems or the
addressees of its existence or contents. If you have received this email
and are not a named addressee, please delete it and notify the Lynx
Financial Systems IT Department on 0113 2892990.
