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