Diskoptimizers
9 messages in this thread
John, you're absolutely right.. I believe the function in question is
DeleteFile(), from dos.library. It would be pretty easy to write something
that would either rename/move the file somewhere else or delete it and
store its block pointer in a data file somewhere. You could control if
files are deleted or not via some sort of env variable probably. (not
saying that I will write such a beast 🙂
Khalid.
I remember you gave me an example of a SetFunction from your LED blinking
code, and I've put it, along with a short text of further ideas for this
program, in a directory on my hard disk – should have been named "Rainy Day
Projects", I think. There are a number of enhancements I can imagine that
would make this very useful… I say, Rename is just what you want, unless
you want this temp directory on a separate volume, which certainly makes
sense if you want to preserve files deleted from floppies. A background
copy could take place after the SetFunction'd function quickly renames the
file to a machine-generated name, and really deletes it when the file is
safely moved. "Deletes" would take a little longer than expected, but that
would be the sole effect.
John, all this is just 'implementation details'. (grin) It isn't difficult
to write, but would need some careful thought first. What I would do is to
do all that and write a couple of commands.. the first is a 'realdelete'
and the second is 'Henry! Take out the trash already, willya!' (grin)
The only problem with renaming is that it doesn't work across devices and
the user would probably have to assign somewhere to be the trashcan, like
the WB trashcan. (or maybe even one and the same?)
Hmm.. I wonder. (thinking)
Khalid.
Khalid, what are we after here anyway? If a deleted file MUST be available
ages later, then you are going to have to save it elsewhere, to be sure it
is available, right? (via Trashcan or such)
But, if what we are after is a way to UNDELETE a file immediately after
deleting it, do you really need to make a copy of the entire file? Hating
to repeat myself, but couldn't you just:
1. create a file on the disk (or on an assigned device) called
UNTRASH.DAT, or something. It would hold the data generated by
the steps below. 2. do the zeroing of the directory entry, but save the
data in
UNTRASH.DAT. 3. change whatever file hashing, etc needs to be done. See
Don Curtis
response in this thread. Save the information in UNTRASH.DAT. 4. make a
copy of the current file disk bitmap in UNTRASH.DAT and the
zero it.
I'm not sure if I have the correct steps in deleting a file down, but the
idea is to save everything you do, so that you can restore it in reverse,
with an UNDELETE command. It would be up to the user to realize that the
disk must not have been written to in the meantime, or else the chances of
success were slim.
I cannot see that this would require much disk space? It allows you to
delete happily, knowing that if right after you complete that DEL <file>
command you can get it right back! (If you're after a long-term UNDELETE,
you'd be taking your chances) Sorry this is so long. –jp–
John, if we're looking for an immediate undelete, then the logical solution
would be something that scans thru the device to find the file you just
deleted. You don't need the overhead of SetFunction()ing the delete call
and storing info. I wouldn't trust this info anyway since it might have
been written over immediately.
A file _can_ be undelete by a simple scan for the file's directory entry
block (or whatever it's called) and then tracking the file down. I'm sure
someone will give you a better explanation. How many times do you think
you will be using the undelete command per week? once? twice? If so,
then the overhead of SF()ing the delete call and keeping track of deleted
files in a file is too much just to save a minute or so per week.
(I hope I'm making sense 🙂
Khalid.
Yeah, you are. I guess I just have a spot in my heart that doesn't want my
Amiga to be slower than the PC at work, where UNdeleting is a breeze.
Different file systems, I know. Oh well…. –jp–
The only fly in the ointment with an undelete is that on a floppy, using
OFS, the BitMap block moves around every time it is rewritten. It often
lands right on the header of the file that you just deleted. In this case,
DiskSalv is the answer (and it doesn't take a real long time on a single
floppy).
-larry
It sounds like you're on the right track but UNTRASH.DAT sounds too much
like a MS-DOS file :-;
—Mike
Khalid (and John),
It's got to SetFunction'ed to RENAME else saving the header block
pointer would be of very little use. The next write to the drive could
easily make that pointer invalid.
By renaming the file into the trashcan directory, it's uniform with
the WorkBench method, and the file wouldn't really be deleted until you
emptied the trash.
Ah…but isn't that a problem then??? Would not 'Empty Trash' also
attempt to go thru the DeleteFile() function? And wouldn't that attempt to
simply rename it to itself? The answer would be yes, so you'd also have to
have your function check for the current location of the file, and if
already in the trashcan…really get rid of it.
Don