ARPUS/ce, Version 2.6.2 (03/10/05) (SCCS 1.9)
_______________________________________________________________________________
Concept: Edit file backup modes.
DESCRIPTION:
Since there may be times at which you will want to revert to a
previous version of a file, ce can automatically create a backup
file before saving a changed version.
There are a number of events that can take place that cause a
file to be updated to disk. In fact, such events can occur
multiple times during a single edit session. A backup file is
created when such an event occurs for the first time during an
edit session.
A backup file is given the same name as the original file, except
that the suffix ".bak" is added to the backup file's name. If ce
attempts to create the "file.bak" file and a file with that name
already exists, the existing version is overwritten. (This should
not be a problem unless files with names ending in ".bak" are
also being generated by some other application.)
By default ce will always create a backup file unless you use the
"-bkuptype none" command line option or the "Ce.bkuptype: none" X
resource specification. Backup files can be created using one of
two modes:
"dm" mode
In this mode, the original <file> being edited is renamed to
<file>.bak, and a new <file> is created. This means that any
hard links that pointed to the original <file> will
subsequently point to <file>.bak. This is because a hard
link actually points to a file's internal system identifier,
and a file that is renamed retains its original identifier.
Specify "-bkuptype dm" on the command line or "Ce.bkuptype:
dm" in your .Xdefaults file.
"vi" mode
In this mode, <file> is copied to <file>.bak. This means
that hard links that pointed to <file> will still point to
<file>, which will be the changed <file> following
termination of the edit session. Doing the copy means that
the file is read in and copied out an extra time. This is
slower than "dm" mode.
Specify "-bkuptype vi" on the command line or "Ce.bkuptype:
vi" in your .Xdefaults file.
"dm<n>" mode
This mode is like dm mode backups except that <n> numbered
backup copies are kept in addition to the .bak file. To
elaborate, assume that <n> is 3 and we are editing file
file.c. This means either "-bkuptype dm3" was specified on
the command line or "Ce.bkuptype: dm3" is coded in your
.Xdefaults file. The first time a save is done, a check is
done for file.c.bak3. If this file exists, it is deleted.
Then file.c.bak2 is renamed to file.c.bak3. Then file.c.bak1
is renamed to file.c.bak2 and file.c.bak is renamed to
file.c.bak1. Finally file.c is renamed to file.c.bak and the
save is performed creating a new file.c, This last part
follows the same logic as the default "Ce.bkuptype: dm"
"vi<n>" mode
This mode is like vi mode backups except that <n> numbered
backup copies are kept in addition to the .bak file. The
processing of the numbered .bak files is identical to the
"dm<n>" mode. The creation of the .bak file from the
original file is done accoring to the rules of "vi" mode.
The default backup mode is "dm". Use the "-bkuptype" command line
option or the "Ce.bkuptype" X resource to change the mode to "vi"
or "none". When turning off backups on the command line, -nb is
an abbreviation for -bkuptype none.
TROUBLE:
A distributed computing environment is a complex entity. Ce makes
use of this environment with such features as display back and
'cc' across multiple workstations. In a complex network, things
can go wrong. The network can go down. A file server can go down
breaking an NFS connection. The machine you are executing on can
run out of swap space. Ce makes every attempt it can to protect
your data in the event of a failure.
In the event of a loss of connection or an interupt (SIGTERM,
SIGQUIT, or SIGINT), ce will attempt to create a crash file. The
steps involved are:
1. Add .CRA to the end of the edit file name and attempt to
save the file.
2. If this fails, attempt to save the file in
/usr/tmp/<filename>.CRA and change the permissions to 700.
This is the /usr/tmp directory on the node Ce was running
on.
3. If this fails, try to save the file in the users $HOME
directory with the .CRA suffix.
4. If this fails, create a directory called /tmp/Ce_CRASH and
attempt to save the crash file in this directory. This is
the /tmp directory on the node Ce was running on.
5. If either of the later three cases succeed, create a soft
link from the first choice place to create the crash file to
the place it was created.
In the event of running out of swap space on the node (normal
cause for "out of memory" errors), Ce will attempt to do garbage
collection by getting rid of storage associated with the undo
command and clear out the contents of the message output window.
If it collects enough space to continue, it then outputs the out
of memory message with a suggestion to save your file. If it
cannot collect enough space to continue, it frees a block of
storage it holds in reserve and attempts to create the crash file
as described above. Then it issues a message to stderr specifying
that it is out of space and it is going to pause. It gives the
process id and specifies that it should be sent a SIGCONT (kill
-25 <pid>) when the out of memory problem has been resolved. Out
of memory problems can normally be temporarily cleared up by
closing applications. Your system administrator can increase your
total swap space.
RELATED HELP FILES:
xresources (Arguments and X resources)
pw (Pad Write)
support (customer support)
_______________________________________________________________________________
Copyright (c) 2005, Robert Styma Consulting. All rights reserved.