Date: Sat, 11 Nov 2017 00:44:53 +0000
From: co...@sdf.org
Message-ID: <20171111004451.ga...@sdf.org>
| This is missing:
| - Moving virecover to /usr/bin
| - Regen'ing autoconf
| - Adding it to default ~/.profile
| - Removing virecover rc script
This is all very "nice" except that I really don't want more dot
files (or directories) in my home directory - if anything like this
were to be done, the location of the save files should be in a directory
set by an env var (a new one) with a default location of where it is now,
though whether that is /var/tmp/xxx or /var/preserve/xxx makes very
little difference - the only reason I can imagine for changing would be
if making /var/tmp a tmpfs was a future goal, and that's not a good idea.
(If it is to be changed, provision needs to be made to deal with old saved
vi editing session backup files from before the change.)
The save files should (where possible) not be on a filesystem (or even
a drive) that is shared with files likely to be edited (which makes /var
a reasonable choice) - that way the temp files are safe when writing the
file back fails because of no space (incl out of quota) or hardware
failures. Keeping them in $HOME is a seriously poor choice.
I don't want e-mail about saved files every time I login - once per
system reboot is already too many - once (ever) would be better.
There are systems on which I login very frequently - I really don't
want virecover mail to turn into spam. On one of my home systems I
tend to create about 10 login windows - from my laptop - every time
either one of them restarts - usually the laptop. On other systems
I never "login" (as in create a login shell which would run .profile)
yet I still edit files there, and being told I was doing that when the
system rebooted is useful info. So using .profile is a terrible idea.
If it really needs to be per user, it would be better in the as an @boot
entry in the user's crontab file (which then forces each user to have
one, want it or not.)
If anything were to change related to virecover (and I really don't see
the need for any changes at all - the best fix would be to make them more
robust. but when you're assuming the system is crashing. for unknown reasons,
just at the time editing is happening, that's not easy) the better
improvements would be to send one e-mail per "event" rather than one
per saved file per event - and if the user is making this happen, then
using the output of "vi -r" is much more rational than having a script
attempt to make sense of the contents of the vi.recover directory.
The one useful change would be to add some indication which file was
being edited, beyond its file name, eg: I currently have ...
andromeda$ vi -r
Wed Oct 18 22:37:28 2017: eval.c
Thu Oct 19 16:59:28 2017: jobs.c
Those are two source files from sh ... I can see from that when I was
editing them last (probably a suspended vi when the system shut down.)
What I don't know is which copy (or copies) of sh they're from, I have
more than a dozen. Knowing the full path names of the files would
help (nb: not the $PWD of the vi at the time, I often edit one shell's
sources while in the directory containing a different version.)
That's why those saved files are still sitting there ... one day I might
remember having been making some updates to one of those files, and be
unable to find the changes I'd made where they should be - then I can go
fetch the saved file and see if it fits ... fixing "vi -r file" so it only
deletes/invalidates the backup when the editor session ends would be
useful as well - that is, not even when the file is written, as it usually
would, so I could "vi -r file" ":w %-saved" ^Z "diff file file-saved"
(observe the changes are not what I was looking for) "fg" ":q!" and the
file would still be waiting to be recovered again sometime in the future.
Incidentally this also shows that saved files are not always recovered
anytime soon after a reboot (or whatever) - I have had files left in
vi.recover for years in the past (which is why the "every reboot" e-mail
starts to get like spam.)
To summarize - apart from bug fixing, there is no need to change anything.
This stuff has been working, to one degree or another, for approaching 40
years now (more than 30 anyway) and in design if not always implementation,
working well - it does what people need, and are used to. That is, there
is no need for some grand redesign. Just (aside from bug fixing when needed)
leave it alone.
kre
