On Sunday 02 November 2003 22:54, Jason Stubbs wrote:
> On Sunday 02 November 2003 21:20, Redeeman wrote:
> > something happend, and i lost all files in a dir, i think i know what
> > happend:
> > i had made a link to the directory in a dir, so that i could share it on
> > ftp, but when i removed the link, the dirs content got deleted too, its
> > around 12gb og zip archives, and windows executables.
> > i have NOT wrote to the disk since, in hope it can get recovered, i had
> > a situation before:
> >
> > i had deleted some files in windows though, and i tried ontracks tool,
> > it found files, but with the name b0rked, but runtimes software found
> > with the correct name, this time i tried ontracks and the name was
> > borked again, but runtimes didnt find anything, not even the files on
> > the dir beyond, so i guess runtimes tool is capable of doing it, but
> > maybe some stuff is needed in order to do it.
> >
> > some of you know how i might be able to recover? maybe its best with a
> > linux tool? the filesystem is fat32
>
> Your best bet would be to not touch it at all. There's a few tools on linux
> that'll allow you to edit at the block level. Read up on them and use them
> to look at the filesystem. At the same time search around for information
> on the structure of the fat32 filesystem. Learn it while looking at a live
> filesystem at the block level and then when you're confident that you know
> what you are doing, you can attempt restoration. If it doesn't work, then
> you know you can change it back and start over.
>
> Personally, I don't know much about the FAT(32) file-system. The only
> filesystem I was ever 100% familiar with was BAM (used on the C-64!) but
> what I do know of FAT16 is that files are marked as deleted by replacing
> the first character of the filename in the directory table and then marking
> the occupying blocks as free in the allocation table. I don't know what the
> implications are for the long-file-names aspect. Once the directory entries
> are restored, doing a regular Windows scandisk should pick up that the
> occupying blocks are marked as unallocated and mark them as allocated in
> the allocation table.
A further thought... don't touch the disk with Windows until you've got the
data of it. When you try accessing it use "mount -t vfat -o ro" under Linux
to ensure that the partition is not touched.
Also, a very good description of the FAT12/16/32 filesystems can be found
here:
http://home.freeuk.net/foxy2k/disk/disk1.htm
Jason
--
[EMAIL PROTECTED] mailing list
