eraps2@aspvax.UUCP (02/10/88)
Hi all,
Does anyone know how to undelete a file? I know ... a basic question,
but the answers "diskslav" and "undelete" don't seem work. I just
deleted a file by accident and WITHOUT DOING ANYTHING after deleteing
the file, tried diskslav and undelete on it. For undelete, I tried the
following:
UnDelete myfile
UnDelete subdir/myfile
UnDelete volume:subdir/myfile,
UnDelete :subdir/myfile,
I can't seem to get it back -- fortunately I had a backup only 4 hrs
old, but I had the same problem last time I killed a file too. FYI, I
deleted the file with "rm" in Csh 2.06 [great program!]. Does the
shell do something funny on delete? Does UnDelete work? Why didn't
DiskSalv get it? Please mail me the anwers to these and other
questions.
Thanks,
Do you think that... I do! Rob Ginn
You can't mean... I'm afraid... ...burdvax!jtids!aspvax!eraps2
But by now she could be... Yes! ...sun!liberty!drexel!aspvax!eraps2
--Trevor Graydon --Jimmy eraps1@nadc.arpacmcmanis%pepper@Sun.COM (Chuck McManis) (02/16/88)
In article <18956@aspvax.UUCP> eraps2@aspvax.UUCP writes: >Hi all, >Does anyone know how to undelete a file? I know ... a basic question, >but the answers "diskslav" and "undelete" don't seem work. I just >deleted a file by accident and WITHOUT DOING ANYTHING after deleteing >the file, tried diskslav and undelete on it. Well, I don't know this for sure, but when you "Delete" something I believe that AmigaDOS scribbles on the FileHeader block. When you "Lose" something because the directory got blown away, you can recover it. The only other way is an extremely crufty walk through the old file system collecting blocks that all point back to the same block. Not fun. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
steveb@cbmvax.UUCP (Steve Beats) (02/16/88)
In article <41962@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > >Well, I don't know this for sure, but when you "Delete" something I >believe that AmigaDOS scribbles on the FileHeader block. When you "Lose" >something because the directory got blown away, you can recover it. >The only other way is an extremely crufty walk through the old file >system collecting blocks that all point back to the same block. Not >fun. > When AmigaDOS deletes a file it does not scribble over the deleted header. In the current file system, the header in question has it's type or'ed with t.deleted and MAY be written to disk in this state (I'm not sure without trying it out). The only headers that have any important info changed are the owning directory and/or the previous header in the hash chain. In FFS the t.deleted thingy has been removed, now only the previous header gets changed and written to disk. The file that was deleted will remain intact exactly where it was before the delete. Oh yes! In the old FS, bitmap pages can be de-allocated and re-allocated when they are written out. If the file that was deleted was closer to the root than the current bitmap then the chances are it will be zonked (though this will probably only affect the data and not the header due to allocation directions). >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. Steve Beats
page@swan.ulowell.edu (Bob Page) (02/16/88)
cmcmanis@sun.UUCP (Chuck McManis) wrote: >when you "Delete" something I believe that AmigaDOS scribbles on the >FileHeader block. It doesn't touch it. It just deletes the entry from the parent's hash table, and fixes up the bitmap. The actual header block and data blocks are untouched. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "I don't know such stuff. I just do eyes." -- from 'Blade Runner'
page@swan.ulowell.edu (Bob Page) (02/17/88)
steveb@cbmvax.UUCP (Steve Beats) wrote: >In the current file system, the header in question has its type >or'ed with t.deleted and MAY be written to disk in this state I've never seen it get written out. t.deleted = 1, BTW. >In FFS the t.deleted thingy has been removed How about t.long? Was there ever any support for that? >If the file was closer to the root than the current bitmap then the >chances are it will be zonked This isn't an issue on floppies, where the bitmap gets allocated at format & doesn't get deallocated, since there's only one. As Steve suggested, it also isn't an issue in FFS, where the bitmap is pre-allocated, based on the size of the partition, at format time. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "I don't know such stuff. I just do eyes." -- from 'Blade Runner'
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/18/88)
In article <2908@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >steveb@cbmvax.UUCP (Steve Beats) wrote: >>If the file was closer to the root than the current bitmap then the >>chances are it will be zonked > >This isn't an issue on floppies, where the bitmap gets allocated at >format & doesn't get deallocated, since there's only one. Uh Bob, if you look at where your floppy bitmap is on your floppy you might be suprised to see that it moves around. I didn't believe this until I watched it closely one day, the thing that fooled me was that it trys to allocate a block near the root, which is right next to root when it is formatted, when it builds a new bitmap it does the same thing only now there are some directory entries nearby so it allocates a block past them. Then on the next update it notices the old bitmap block is free so it uses it again. Basically, it ping pongs back and forth. And when you fill up the disk (no free blocks) it won't write out a new bitmap, it just leaves the flag saying the bitmap is invalid. The validator will fix it up the next time it runs though. Same thing happens on hard disks as far as I can tell. Steve, does it still move on FFS systems? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
steveb@cbmvax.UUCP (Steve Beats) (02/18/88)
In article <42225@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <2908@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >>steveb@cbmvax.UUCP (Steve Beats) wrote: >>>If the file was closer to the root than the current bitmap then the >>>chances are it will be zonked >> >>This isn't an issue on floppies, where the bitmap gets allocated at >>format & doesn't get deallocated, since there's only one. > >Uh Bob, if you look at where your floppy bitmap is on your floppy you >might be suprised to see that it moves around. ............ >.......Steve, does it still move on FFS systems? > No way, Jose! FFS allocates the bitmap as soon as it can (ie when the disk has just been formatted), and leaves it there permanently. There is one possibly nasty side effect from this though. If the bitmap gets allocated in a really wierd place or is fragged up a lot then it will remain that way. I can't think of any case where this could happen with the current FFS because you can't write to a disk that is validating (and hence can't steal blocks from the bitmaps preferred area). But, when FFS gets updated (soon) and supports old FS format, there could be some gotchas. Imagine a floppy that is 100% data, no bitmap block allocated. This is perfectly legal as you pointed out Chuck since the validator will construct a bitmap in memory. As soon as you delete a file from this disk, the bitmap will use whichever key becomes available first. If this is off to the edge of the disk, than that is where it will stay. I made the decision that since the bitmap is only accessed during startup and the 3 second update, the performance hit would be acceptable. Wanna hear a horrible fix? Delete a file that is known to be close to the root and reboot the machine after it has finished but before the 3 sec write has occured. On re-boot, the validator will construct a new bitmap and allocate it in the space left by the deleted file. Of course, this would only be an issue on floppies that were created using oldFS and were subsequently used with the compatible version of FFS. Steve