Re: linux-2.5.4-pre1 - bitkeeper testing

Mark H. Wood (mwood@IUPUI.Edu)
Mon, 11 Mar 2002 20:28:27 -0500 (EST)


Okay, I looked this up in the _VMS I/O User's Reference Manual: Part I_
for VMS v5.0 (latest I have in the programmer series -- they tore out our
single VMS system so that they could install two dozen hefty Windows boxes
to almost replace it).

I can find nothing explicit about creating directories (something that
virtually no one did at the $QIO level) so I'm *assuming* that one just
executes SYS$QIO IO$_CREATE|IO$M_CREATE using a filespec of the form
"somename.DIR;1", passing a file attribute descriptor of ATR$C_UCHAR with
FCH$M_DIRECTORY set, and a record attribute block with FAT$W_VERSIONS set
to the desired version limit default for the directory. Files entered
into that directory will get their limit set to this default unless they
are created with FIB$W_VERLIMIT nonzero. It looks as though this
defaulting mechanism is applied to subdirectories when they are created --
the system management essentials volume (I don't have the title handy)
makes special note that putting a version limit on the MFD (think of it as
the directory that the superblock points at) will cause that limit to
trickle down to all inferior directories.

Anyway it looks like this is how it works (and this is the way I remember
it): setting a version limit default on a directory causes any file to
have that version limit unless the file is created with or modified to
have an explicit version limit of its own. Subdirectories take on the
default limit of their superiors, so their dependent files will get the
original limit unless the subdirectory's limit default has been modified
or they are created with an explicit limit. Changing a default in any
directory only affects files subsequently created in that directory and in
any subsequently created subdirectories.

You can specify whether creating a file will supersede a file with equal
version number, or fail due to a file of that name already existing.

So to boil it down still further: if you usually want four versions
retained, set your home directory to default to four before you create any
files or subdirectories and you're all set. If you change your mind for
some file or directory, you can alter its limit/default with SET
FILE/VERSION_LIMIT or SET DIRECTORY/VERSION_LIMIT. The limit is a
per-file attribute with a per-directory default.

Ordinary users, and even ordinary programmers, never see this stuff; they
use a library called RMS which does the tedious directory-tree walking and
other messy $QIOs. Only a few of us are sick enough to use the ACP-QIO
interface. :-)

The oldest-version deletion magic only chops off the single lowest
version, so if you have four versions of FOO.BAR and you set the top
version's version limit to two, then create a fifth version, only the
first version gets deleted. To sync. up after lowering the version limit,
you must execute a PURGE command (or your code can contain equivalent
logic).

The version number does not wrap; when you get to version 32767 you cannot
create any more versions. This was actually used to foil the only malware
I ever heard of on VMS systems, which tried to create a copy of itself
under a name that had special meaning to the DECnet ACP. Setting that
file's version number to 32767 broke the WANK worm's infection strategy,
and was widely done until the worm-enabling bug was patched.

We probably ought to take this discussion somewhere else if it is to
continue, since I expect that the vast majority of LKML readers are
heartily sick of all this VMS gobbledygook. None of it has anything to do
with what most people think of as revision control.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Our lives are forever changed.  But *that* is exactly as it always was.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/