Path: utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: TxEd Plus problems and a gotcha with the FFS Message-ID: <5233@cbmvax.UUCP> Date: 14 Nov 88 19:24:46 GMT References: <1070@esunix.UUCP> Organization: Commodore Technology, West Chester, PA Lines: 34 in article <1070@esunix.UUCP>, blgardne@esunix.UUCP (Blaine Gardner) says: > Ok, move onto DiskSalv then. But after running disksalv there is no > trace of the deleted file. No writes were done the hard drive after my > screwup (in fact I used the LOCK command to make sure!), but the file is > not there. Am I correct in assuming that some of the redundancy of the > OFS was traded for the speed of the FFS? Yes, that's true. It's only data block redundancy that's gone, though. The file headers and directory headers are supposed to work as before. However, I have noticed that they (eg, deleted blocks) seem to get strangely modified in ways I never saw in SFS. I'm nearly done with a release of DiskSalv that's address some of this behavior, as well as fixing up a bug or two, but I'm not sure how to explain it. As far as the contents of a file, that redundancy is gone. Where in SFS there are two ways to get to each 488 byte chunk of a file, FFS chunks in 512 bytes and leaves only one path to each chunk. This does allow it to be fast, though, since you can load a bunch of consecutive chunks directly, whereas with SFS, the header would have to be stripped from each chunk before it's used. > It looks like daily backups from here on out. Good idea, anyway. Not saying I ever do it, either, but it's a good idea. (actually, I do backups every so often, and I'd recommand LV Backup by MkSoft to anyone not happy with one of the numerous PD backup programs around). > Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession