blgardne@esunix.UUCP (Blaine Gardner) (11/09/88)
[Will someone remove all sharp objects from the room so I don't injure myself?] Problem #1: TxEd Plus can't deal with an apostrophe in a directory name even though it is a legal character. Problem #2: I haven't been able to verify what caused the problem, but last night TxEd Plus was refusing to save a modified file under the original name. It would save the modified file to "Txed.temp", but the original file was never touched. Nothing has changed since the last time I successfully used TxEd except for replacing NEWCON: with ConMan 1.3's NEWCON: mountlist entry. I doubt this was the problem since it was still there after switching back to NEWCON:. (ARGH! I also installed ARexx on my hard drive, perhaps it's doing me a "favor" behind my back?) That problem is annoying, but the real killer is that due to a combination of command history, fast fingers, and a slow brain, I deleted my startup-sequence. Ok, no problem, just get undelete. What do you mean "Insert disk in DF0:" ???? 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? Ahhhhhhhhhhhhhhh It looks like daily backups from here on out. -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 Here: utah-cs!esunix!blgardne {ucbvax,allegra,decvax}!decwrl!esunix!blgardne There: uunet!iconsys!caeco!pedro!worsel!blaine (under construction) "Nobody will ever need more than 64K." "Nobody needs multitasking on a PC."
daveh@cbmvax.UUCP (Dave Haynie) (11/15/88)
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