On Sunday 02 November 2003 23:29, Jason Stubbs wrote:
> 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
Forget all that I've said. Unless you've got a _lot_ of time, you have to
reconstruct which clusters belong to which file and in what order if doing it
manually. I'd like to know how the undelete programs successfully (?) figure
that! Anyway, I found this Q&A with several links (and links to links) that
should find you something that will work. If you have the space to spare,
maybe you should use dd from linux to back up the raw partition first?
Anyway, check here:
http://beta.experts-exchange.com/Miscellaneous/Q_20780127.html
Jason
--
[EMAIL PROTECTED] mailing list
