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
Re: [ql-users] Assembly question
Robert Newson wrote: Looking at the 1/-1 column (closest, as I've got 2/-127), I see that N is set and so branch should be taken. However, N is in fact clear - N,Z are clear and C,V are set: using 2's complement and adding (I learnt MC programming on a 6502) you can see this: -127 = 1000 0001 - 1000 0001 +2 = 0010 - 1101 [1's complement] 1 [extra [initial] 1 for 2's complement] --- 1 0111 C = 1 : Obvious Obviously it's not that obvious. ;-) It is true that the result of an addition with NEG(op) equals an subtraction with op, but not when it comes to the flags. If you do a direct subtraction you see that at the end there is no carry involved. -127 = 1000 0001 Destination +2 = 0010 Source 0 1110 Carry bits -- 0111 Marcel
Re: [ql-users] Q-Trans Trash can
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
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
Re: [ql-users] Assembly question
P Witte wrote: Robert Newson writes: ... No need for the homework: I like your table and will adopt it forthwith! I particularly liked the compressed logical expressions for the flags. Per Sorry to admit it, but it isn't mine (only the comments, plus the DBcc extensions, are mine); I got it from Quick QL Machine Language by Alan Giles (my 68k tutorial...I actually originally learnt 6502 from The Pet Revealed and the Acorn Atom manual; later was I given the 650x manual for reference - especially with regard to what's done in each clock cycle of an instruction).
