To ensure that hclnfsd gets restarted at reboot, create a script called
/etc/init.d/hclnfsd (or download it directly from hclnfsd).
#!/bin/sh
# PC NFS daemon; so that PCs can map exported UNIX drives via NFS Maestro.
hclnfsd_home=/usr/local/hclnfsd
case "$1" in
'start') if [ -f $hclnfsd_home/hclnfsd ]; then
echo "PC nfs daemon (hclnfsd) starting"
$hclnfsd_home/hclnfsd -A -X
else
/usr/bin/echo "\n /etc/init.d/hclnfsd ERROR: cannot find PC nfs daemon $hclnfsd_home/hclnfsd \n"
fi;;
'stop') PID=`ps -efl | grep hclnfsd | grep -v grep | awk '{ print $2 }'`
[ ! -z "$PID" ] && /usr/bin/kill ${PID} 1> /dev/null 2>&1;;
*) echo "Usage: /etc/init.d/hclnfsd { start | stop }";;
esac
Change permissions on the new hclnfsd file to make it executable and
setup the run control links to it.
# cd /etc
# chmod 744 init.d/hclnfsd
# ln -s /etc/init.d/hclnfsd rc3.d/S99hclnfsd
# ln -s /etc/init.d/hclnfsd rc2.d/K00hclnfsd
Start the hclnfsd daemon.
# /etc/init.d/hclnfsd start
Back to the INDEX.
Cannot run regedit
This is an error you receive on NT when a software package,
such as clearhomebase.ccreg, is executed. This says that you don't have
the proper permissions to edit the NT registry. The simple solution for
this is for an Adminstrator to give the "SYSTEM" permission to edit the registry.
Back to the INDEX.
rcmd: socket: permission denied
This error shows up when trying to checkout an element in a newly
integrated VOB. This error is independent of CC. I.E. Independent
of CC, you should be able to successfully run an rsh command on the
command-line. The integrated CC system uses the rsh command to log
into the DDTS server and run some commands.
The solution was that, somehow, the executable /usr/bin/rsh was not
owned by "root" with a group of "bin". The permissions for it should
be set 4555. That is, setuid "-r-sr-xr-x".
Back to the INDEX.
The VOB storage directory "X:\\server\path\vob.vbs" was not found.
This error occurs when you are trying to mount a VOB or start
a view and CC complains that it can't find a VOB storage area on a drive letter that has
nothing to do with the task at hand. That is, that particular drive
letter is not mounted to anything, nor are you requesting a view or
VOB be mounted there.
Somehow the system still thinks that the VOB/view is accessed through
that drive letter, perhaps because it was there in the past. If there
is no reference to it in the NT Explorer, run regedit and see if there
are any references to it and delete them: HKEY_USERS -> serial-number -> Network.
If there is more then one serial-number, there will only be one
with a "Network" subfolder. If there is no entry for the drive being
mentioned, try a reboot. The extreme solution that is known to clear
up this problem is to reinstall CC :-(.
Back to the INDEX.
Unable to open file "/tmp9999.pmt": permission denied
This error message shows up anytime CC tries to write a file to the
directory pointed to by the environment variable TMP. This error is most likely to
show up when trying to checkout an element in a newly integrated
VOB. The problem is in the Perl script
atria-home/sun5/lib/perl5/integ/clrcase.pl. The 2 lines below
are trying to write to an output file based on the environment
variable TMP. If TMP is set to "/tmp", there is no slash between
the environment variable and the filename. So, after concatenating
the two, you wind up with an erroneous name appearing in the
"/" directory, which understandably gives you "persmission denied".
$outfile = $ENV{'TMP'} . "$$.pmt";
$cmd = fmtcmd("clearprompt","text -outfile $outfile $def -prompt \"${bugmsg}\"");
The solution, until Rational fixes that script, is to reset the
TMP environment variable to TMP="/tmp/".
Back to the INDEX.
ClearCase albd service did not start.
Error 1069 - The service did not start due to logon failure
This error shows up on an NT when the albd service has not started
for some reason. One reason this can occur is if the clearcase_albd
user password has expired. A quick test to see if this is the cause
is to try and login as clearcase_albd. If this is the problem,
reset the NT password for clearcase_albd. The clearcase_albd password
is registered in two places, on the NT system in Start -> Programs
-> Administrative Tools -> (Domain) User Manager. Be sure to set the switch
"Password Never Expires" to avoid problems in the future. In CC,
Start -> Settings -> Control Panel -> Services and double-click on Atria Location Broker.
Back to the INDEX.
cleartool: Error: Pathname is not within a VOB: "."
Any ct commands that have to do with listing or manipulating elements
must be done with a view set and inside a VOB directory. If the
vob-tag for a VOB is "/clearcase/vobs/scripts", then you need
to be cd'ed to that directory of one of its subdirectories to work
with CC commands. This excludes some commands: lsvob, lsview,
clearlicense, etc ...
Back to the INDEX.
element [checkedout but removed]
This is due to an element that is checked out to a view, but the
view-private file either could not be written to that directory or
was subsequently deleted. Have the person that owns the checkout
do an uncheckout on it. It could be that the view storage directory
does not have permission for you to write to it. Also, check the
permissions on the parent directory and ensure that
the group has read-write privileges. If permissions on the parent
directory and the view storage area seem ok, the view-private file may
just have been inadvertently deleted. Have that user try another
checkout and see.
This is analogous to a snapshot view's
[loaded but missing].
Back to the INDEX.
The path \DEVICE\...\...\.s\filename does not exist.
This error is associated with trying to remove or overwrite a view-private
file via an NT client when the actual data container has been deleted
for some reason. That is, if there is a view-private file called "junk" and it
has a data container /admin/clearcase/views/admin_view.vws/.s/00032/bbbc8a3b.000f.junk
and that storage area gets deleted for some reason without removing it via
the view in the VOB, you will get the error message.
This message only occurs if trying to remove the view-private file via
an NT. If the view is common to both UNIX and the NT client, set the view
on the UNIX side and just delete the view-private file from the VOB directory.
If the view is local to the NT, there is no way to delete the view-private file
from the VOB directory. Go to the view container directory pointed to by the
error and create an empty file with the same name. You will now be able to
remove it from the VOB directory normally.
Back to the INDEX.
mvfs: ERROR: ... view needs reformat
mvfs: ERROR: VIEW = view-tag VOB = vob-tag - ClearCase view error
A view usually only needs a reformat if the version of CC has been
upgraded. However, a view can occasionally, inexplicably need reformatting
after a system crash or similar mishap. The "reformatview"
subcommand leaves a directory called db.dumped in the vws directory that
can be deleted via normal OS commands. This command can lead to data loss;
this can happen if the element's owner is not the same the view's owner.
Consult the view_log to investigate possible data loss. If the reformat does
not clear the "view needs reformat" error, you may have to consider deleting
the view and creating a new one. Also, consider using the -force
option if you get the warning message "Recovery not needed"; see the CC Reference Manual for details.
# ct reformatview -tag view-tag
On rare occassions a view can become corrupt. If this happens, generally a recover
of the view will solve the problem. If not, call tech support.
# ct recoverview -tag view-tag
WARNING: Recoverview uses reformatview. Depending on the state of the database,
certain information can be lost. Upon completion, check the view_log to investigate
possible data loss; it's in /var/adm/atria/rgy/log on UNIX and ClearCase Home Base ->
Administration -> Log Browser on NT.
NOTE: Sometimes the "db" database directory cannot be renamed due to files
in use. It will reattempt 2 more times at 60 second intervals waiting for the competing
process to finish. If the reformat fails for this reason, ensure no processes are using
the view and try again.
Back to the INDEX.
mvfs: ERROR: view=view-tag vob=vob-tag - ClearCase vob error
This error occurred on Solaris while attempting to cd to a VOB. There could be many
problems that could give such a generic error message, but this time it was caused
by the atria daemon not running. Simply attempt a stop and restart. As root:
# cd atria-home/etc
# ./atria_start stop
# ./atria_start start
Back to the INDEX.
Can't get primary GID
This error shows up when running creds or credmap on an NT that you
are trying to connect to a UNIX server. The problem is that CC doesn't
know what your primary group name is. Need to set a user environment
variable called CLEARCASE_PRIMARY_GROUP to the name of the user's primary group that is on the
UNIX server. You will also need to create a Domain group of that name with
the current user as a member. If unable to create Domain groups, a local group
can be created with the same name locally on the NT client. The only downside
to local groups is that they are difficult to administer en masse in the future.
Back to the INDEX.
Attempt to get location information failed: Invalid argument.
This error can occur when attempting to do commands such as mktag from an
NT client connected to a UNIX server. If the attempted command looked like
# ct mktag -view -tag new-view-tag viewstore/new-view-tag.vws
it may be necessary to include the extended path information
# ct mktag -view -tag new-view-tag
-host server-name
-gpath UNC-pathname
-hpath path-on-server
UNC-pathname
ex: ct mktag -view -tag admin_view
-host scm
-gpath \\scm\viewstore\admin_view.vws
-hpath /viewstore/admin_view.vws
\\scm\viewstore\admin_view.vws
Back to the INDEX.
clearimport: Error: Permission denied. Not VOB owner.
This error showed up when attempting a clearimport as a regular user on an
NT client connected to a UNIX server. All the permissions and connections
were in place to allow the NT user to create and remove elements in the
current directory. However, the clearimport command was giving a "Not VOB
owner" error message. It is essential to be the VOB owner (or root) to do
a clearimport.
The work around for this is to use the -nsetevent option
during clearimport. This is because the original was apparently owned by
somebody else and by doing the clearimport you are telling CC to create an
element owned by the other person, which is not allowed unless you are the VOB
owner or an Administrator. Using the -nsetevent option creates the newly
transferred element as you with a new creation date. The downside of this
is that the original creator and creation date history information are lost.
Back to the INDEX.
Type manager "..." failed construct_version operation.
This error showed up when doing an update view for snapshot view on an
NT. For some reason the view_server.exe process had gotten confused
and a reboot solved the problem. This was also coupled with permission
denied errors where there were none previously.
Back to the INDEX.
element [eclipsed]
This shows up when you do a "ct ls". It means that there is
a view-private file of the same name eclipsing the source-controlled
version of the same file. This can happen when a user adds a file to
a directory and leaves it view-private. Then, another user in a
different view goes to that directory, seeing that the expected files
are not there, copies them in and adds them to source control. Now,
when the first user returns to that directory and does a regular "ls",
they will see their own view-private version of the file. However,
it they do a "ct ls", they will see two versions, one view-private and
the other in CC but eclipsed.
There are two solutions to get out of this and depends on which version
is to be kept. If the view-private version in the first user's
view isn't needed, then simply delete it and the CC version will be
visible in the normal way. If it is needed and
needs to be added to source control, move the view-private file to a
temporary name, checkout the now visible CC version, move the temporarily
named view-private file back to the original name overwriting the CC
version and then check it in. Of course, there is always the third
option of removing or renaming the CC element.
Back to the INDEX.
Could not find ".\lost+found" in directory hash table.
This error showed up when attempting a clearimport using a cvt_data file
generated by clearexport_ccase. The cvt_data was generated sitting on top
of another VOB, which necessarily has a lost+found directory at that level. The error
message is telling you that the lost+found directory in the original VOB
has elements in it. There are two ways to get around this error. Rmelem
on everything in the lost+found directory in the original VOB and rerun the
clearexport_ccase the same way, or rerun the clearexport_ccase specifying
everything in the original directory with the exception of the lost+found
directory. Remember to delete the cvt_data file before running clearexport
again.
Back to the INDEX.
The mount-over directory "..." was not found.
This error occurred when attempting to mount a newly created
private VOB. Unlike public VOBs that automatically create the
mount point for MVFS, private VOBs require that the mount point
be a real directory. Create the mount point
and try the mount again. For instance, if the vob-tag for the private
VOB in question was created as /home/ejo/myvob, there
needs to be an empty directory called myvob in ejo before you
mount the VOB.
However, if you're sure the directory in question exists and
you still get the error message, it may be that the directory
"/home/ejo" is itself a mount. The error occurs in this case because MVFS is
attempting to mount the VOB in an NFS mount, which isn't allowed.
To get around this, rmvob on the private VOB and recreate it with
a tag located in a directory local to the machine.
Back to the INDEX.
ClearCase Dynamic Views: The device is not currently connected, but is a remembered connection.
This error occurs when an NT user with a view set simply logs out and back in
vice rebooting the machine. This is a known bug with NFS Maestro and is not fixed in
the latest version 6.1. The only recourse at this time is to either simply lock the screen when
you leave or turn the machine off.
WARNING: Ignoring this error message will cause your Windows GUI to look
like it's working. However, if you try to checkout a file, it will checkout the file but
not populate the current view with it. The result will be the
[checkedout but removed] error message when doing
a "ct ls" of that directory from the command-line.
Back to the INDEX.
cleartool: Error: Cannot link directory "...".
This error showed up when running a "ct ln" command on a directory
on the UNIX command-line. By default, links in CC are hardlinks so
that the link has all the functionality of the original with respect to checkins
and checkouts. However, you cannot create a hardlink to a directory
in UNIX, hence not in CC either.
An alternative to this is to create
a softlink using the -slink option with the caveat in mind
that not all CC functions will be available to the linked element.
Another alternative is to create the destination directory element with
a "ct mkdir" command and then use a "ct ln *" command to link all the
elements inside the directory en masse.
Back to the INDEX.
Cannot set the file time handling property: Permission denied.
This error shows up when a user other than the owner tries to update a snapshot
view. The RPC view_setprop can only be executed by the owner. This doesn't
NEED to be true and Rational is working on a fix: Defect #29605. As a work-around,
you can update each VOB mounted under the view individually. This can be tedious
if working with many VOBs, so an alternative is to add the user getting
the error to the "clearcase" group; the one that only has clearcase_albd in it.
Note that adding a user to the clearcase group gives that user unlimited
abilities WRT ClearCase. That is, that user can rmelem even if the element is
locked and other such undesirable side-affects.
Back to the INDEX.
element [view-->vob hard link]
This shows up when a UNIX hard link is made to a CC object inside a VOB. This showed
up when a user did a UNIX "ln" by mistake vice the "ct ln" and wanted to undo the command. Do not
do rmelem or UNIX rm on it or the original will disappear as well. To get rid
of it, use the UNIX unlink command, which should work. If it runs
without error but fails to rm the link, try doing an unco on the parent directory
and then run the UNIX unlink.
Back to the INDEX.
Unable to load "...": unknown error in VOB.
This error showed up when attempting to update a snapshot view. This is
a generic error message though, and implies that a proper connection to
the vob storage area could not be made. The error is most probably due to
a permission problem in the view, the NFS mount or the VOB.
Some things to look at:
1) Can you map a network drive to the vobstore independent of CC?
2) Re-register the user via "nfs register" on the command-line.
3) Is the snapshot view owned by you?
4) Does the VOB have the correct permissions for your group?
5) Can you create a dynamic view to the same VOB and checkout/in ok?
6) Does credmap pass?
Back to the INDEX.
clearviewtool/view: Error: Unable to create snapshot view "...".
This error occurred when attempting to create a snapshot view in a shared directory.
Even though the share's permissions were wide open, clearviewtool was still giving
permission denied. Unfortunately, all attempts to correct the problem failed short of
simply creating another share and creating the snapshot view in the new share.
Back to the INDEX.
cleartool: Error: Operation "vobsvr_get_handle" failed.
This error showed up when attempting to lock a VOB on a UNIX system. The cause
was that the permissions in vob-storage-area/.identity directory were not set
properly; most likely due to a restore not preserving the permissions or somebody
coming in afterward and changing the permissions manually independent of CC.
The solution to restoring the permissions was to run the following in the .identity
directory:
# chmod 2400 gid group.*
# chmod 4400 uid
Back to the INDEX.
Operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable.
This error showed up when attempting to start a previously working local view on Windows.
The reason for the corruption of permissions is unknown, but the following straightened
them out.
A disconnect in the view's permissions can occur if the Atria Location Broker server logon
user was changed after the view was created or if the view's storage area was moved using NT
commands.
If the error persists after running fix_prot, run it again and then
reboot to reset any caching. One might also consider simply removing the view
and creating a new one. You will need to have administrative privileges to do that.
See "Fix VOB protections" for the fix_prot commands.
Back to the INDEX.
cleartool: Error: unknown style protection on "...". The data is invalid.
This error occurred when attempting to remove a group from the groups list of a VOB
as the ClearCase administrator on Windows. The administrator should be able to remove and add
groups at will. For unknown reasons, the protections on the VOB were not optimal.
See "Fix VOB protections" for the commands.
You'll probably need to stop and restart the albd daemon in ClearCase Home Base ->
Administration -> Control Panel -> Services Startup for the changes to showup.
Back to the INDEX.
cleartool: Warning: Unable to move private data from "..." (No such file or directory). (NT Explorer)
Unable to temporarily move file "..." for element creation. (Command Prompt)
This error occurred when simply attempting to transition a file from view-private
to source control on Windows NT using a UNIX VOB server. Rational reports that this
is due to a mismatch in the way CC 3.2 and NFS Maestro are making calls to the file.
The solution was to upgrade CC to 3.2.1.
Back to the INDEX.
cleartool: Error: Trouble contacting registry on host "...": specified host is not a registry server.
This error occurred on an NT server that was previously working fine.
For inexplicable reasons, the server daemon got "out of sync". The resolution
was to ensure the configuration in the ClearCase Home Base -> Administration ->
Control Panel -> Registry tab was set properly and then restart the daemon in
the Services Startup tab.
Back to the INDEX.
vob_scrubber: Error: Unable to get VOB tag registry information for replica uuid "...".
This error shows up in an email sent to root. This error can show up if a VOB was deleted
in a non-ClearCase manner. There will usually be another email message sent at the same
time telling which VOB failed the scrub. If not, the replica uuid can be correlated to a
vob via the /var/adm/atria/log/scrubber_log or /var/adm/atria/rgy/vob_* files.
Use the procedure at the end of Delete a VOB to ensure
a proper cleanup VOB deletion.
If all the pieces of the VOB deletion are complete and you still get the email
referencing that VOB, as root start and stop the atria daemon:
# cd $ATRIAHOME/etc
# ./atria_start stop
# ./atria_start start
Back to the INDEX.
clearviewtool/server_id_nt: Error: unable to set access control list for ...vws: Access is denied.
clearviewtool/server_id_nt: Error: protection on ...vws is out-of-synch with identity.sd and groups.sd
clearviewtool/view: Error: Failed to set identity on view: Permission denied
These errors occurred when attempting to create a view in an NT shared directory in
which views had been created before. For inexplicable reasons, the
share, not the directory itself but the share, had "Change" permissions only for the
group of users that needed to create views there. Changing the permissions for
that group to be "Full Control" solved the problem.
Back to the INDEX.
cleartool: Warning: The view cannot be started because the MVFS is not installed.
This error showed up after a disk crash and restore from backup. Unfortunately, we were
unable to find the reason the MVFS refused to start. However, CC on the server needed to be
upgraded from 3.2 to 3.2.1 anyway and all was fine after that.
Back to the INDEX.
scrubber/scrubber: Warning: skipping VOB "..." due to earlier errors
This error was written in the /var/adm/atria/log/scrubber_log on a Solaris 2.5.1
server running CC 3.2.1. The scrubber_log was pointed to by a cron job email
stating that ccase_cron.day had failed. The exact reason for the error is unknown,
but the application of patch clearcase_p3.2.1-9.sun5.tar.gz cleared the problem.
Back to the INDEX.
Version checkout "..." is different from version selected by view before checkout "..."
element\CHECKEDOUT from "..." [not loaded, checkedout but removed]
Failed to get stat for the mounted vob pathname.
These errors occur when attempting to checkout a version of an element other than the one
selected by a rule in a snapshot view config_spec. Each of these errors occurred when running the checkout
from the Version Tree Browser and showed up while using CC 3.2.1 on an NT.
Because one of the rules in the config_spec covers
looking at CHECKEDOUT versions, these operations should be allowed.
If you attempt to checkout a version other than the one
selected by the view from the command-line, CC will simply checkout the version that IS
selected by its config_spec and not the one requested. Once the error has occurred, the element will
be missing from the Windows GUI and will give the [checkedout but removed] error
with a "ct ls" on the command-line. From the command-line, "ct unco element";
this will restore the element to normal. However, for snapshot views you will get
an error about an update failure and other messages. For those, simply run
"ct update element" and all should be back to normal. If you really
want to checkout a different version, you'll have to modify your current config_spec
or use a different view to get around these errors.
Unfortunately, it gets more complicated. If you are on a CC system where checkout
of a non-selected version does not generate these errors, you can see differing
behavior WRT linked elements. That is, if you checkout a non-selected version from
one of the linked elements, you will get the version you expected. However, if you
checkout a non-selected version from the the other half of the link, you will get
command-line like behavior in which the it checks out the version previously selected
by the view, and NOT the one you expected. :-(
NOTE: These errors do not always occur. That is, some installs of CC will behave
in snapshot views just like you'd expect in all cases (except the linked element
arrangement).
Moreover, in dynamic views, checkout of a version you are requesting will not default
to the one selected by the view's config_spec as in snapshot views. A subsequent
checkin will simply create a new version via a merge with whatever
the LATEST version was and the view will go back to selecting the old version it
was seeing before. This is true for the linked elements case as well. That is,
all versions of all elements always point back to the original in the VOB and
behavior is much more predictable.
Back to the INDEX.
cleartool: Error: checked out version, but could not copy data to "view" in view: Invalid argument
This error showed up on an NT client connecting to an NT server. Both the client
and NT server were running ClearCase 3.2.1. The user had previously
been able to use this VOB and view successfully. Attempts to checkout any element with this
view failed with the above error message. Other users of the same view and VOB had no trouble
checking out elements. The reason for the error is unknown,
but a reboot of the client machine solved the problem.
Back to the INDEX.
element@@ [no version selected]
element: No such file or directory
These can occur when your view's config_spec fails to select any version of a
particular element. The first resulting from "ct ls" on UNIX or NT and the second results from
a regular "ls" on UNIX; a regular "dir" on NT simply won't show the files.
In UNIX, there is no way to not select a version and not get errors.
Back to the INDEX.
cleartool: Error: Trouble looking up element "element" in directory "directory".
mvfs: error in the configuration specification for view view-tag
./element: I/O error
These errors occur if the view's config_spec has a rule that selects more than one version;
the first during "ct ls" and the other two during a simple "dir" or "ls". Examine the element
via the describe and lsvtree
commands and also the config_spec via "ct catcs" and determine which rule is selecting more than one version.
Back to the INDEX.
cleartool: Error: Trouble contacting registry on host "host: specified host is not a registry server.
This error shows up when attempting to lsview, lsvob or other such commands that need to
query the registry server. On NT, set host correctly in
ClearCase Home Base -> Adminstration -> Control Panel -> Registry on either the client
or on the registry server itself. On UNIX, ensure the host is correct in
/var/adm/atria/rgy/rgy_hosts.conf on both the client and server.
Back to the INDEX.
A duplicate file name exists, or the file cannot be found.
mv: cannot rename element: Read-only file system
The first occurs on NT when attempting to rename a CC versioned file with the
standard "move" command. The second is an attempt to use the standard UNIX
"mv" command. To rename an element, use the CC equivalent:
# ct mv oldname newname
Back to the INDEX.
cleartool: Error: Invalid string value: string.
This occurs when attempting to make/modify a string type attribute.
String attribute values must be enclosed in quotes inside CC. Both
the NT and UNIX command-lines strip the quotes, so they need to be
escaped.
# ct mkattr attribute \"string\" element
Back to the INDEX.
cleartool: Error: Branch "branch" of element is checked out reserved by view view-tag ("hostname:viewstore").
This error occurred when attempting to relocate an element to another VOB. The relocate command
will automatically check out the destination directory for you, but cannot if it's already
checked out to another view. Simply check the destination directory in using the view-tag view
and rerun relocate.
Back to the INDEX.
sh: bugval: not found
CC 3.2, DDTS 4.1, Solaris 2.6
This error shows up when attempting a checkin/out in a VOB integrated
with DDTS. Ensure that the BUGTRACK_PROXY_HOST environment variable
is set to the hostname of the DDTS server, if not the local machine.
Ensure the BUGTRACK_PROXY_USER environment variable is set to the name of
a user on BUGTRACK_PROXY_HOST that you can rsh into and run the getpolicy
command. That is, independent of CC the following command should be successful:
# rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER getpolicy
NOTE: I've noticed that even if this command doesn't run correctly
from the command-line (command not found) that it will run correctly
when called from CC if at the very least the following command IS
successful:
# rsh $BUGTRACK_PROXY_HOST -l $BUGTRACK_PROXY_USER ls
Back to the INDEX.
cleartool: Warning: Version checked out ("new-version") is different
from version selected by view before checkout ("old-version").
This warning needs to be taken seriously. It means that the CHECKEDOUT rule is
currently selecting the element, and when you check it back in,
you will no longer be looking at the version you were just editing. Obviously
this can lead to confusion and possible errors. Change the rules in your
config_spec
so that that particular version is selected whether it's checkedout or not.
Back to the INDEX.
clearviewtool/xdr/albd: Error Unable to contact albd_server on host 'hostname'
clearviewtool/cmd: Error: Unable to create view "viewstore-UNC-path".
Error 1067: The process terminated unexpectedly.
In one case, the first 2 errors occurred when attempting to create a Windows view.
The problem was that the albd service was Stopped. An attempt to Shutdown and Startup the albd service via the
ClearCase Properties failed. An attempt to Start the Atria Location Broker in Start -> Control Panel
-> System -> Services generated the 3rd error.
This error is most likely caused by an albd user or permission problem or clearcase group problem.
Check all of the following. In the Windows Services applet, go to the Properties of the Atria Location
Broker. Under "Log on", ensure the clearcase_albd user is correct (DOMAIN\username) and that the password
is correct. Also, start regedit and check the ClearCaseGroupName (DOMAIN\groupname) registry key value in
HKEY_LOCAL_MACHINE\SOFTWARE\Atria\ClearCase\CurrentVersion.
In another case, the first two errors occurred on a Windows box connecting to a UNIX server via NFS Maestro.
The problem was that the IP address as reported by ping (DNS) was not the same as that
reported by ipconfig (DHCP).
If a network is running DHCP (dynamic IP addresses), the IP dynamically assigned
must be propogated automatically to the DNS tables. This was not happening on the
system in question. If the network admins are unwilling/unable to ensure automatic
update of DNS based on the current DHCP IP assignements, then you either must
set the DHCP lease to be a very long time (so that DNS has the correct info) or
not use DHCP and assign a permanent IP to the Windows client.
Because of the inherent problems with ensuring IP addresses are propogated correctly
throughout a network, Rational recommends static IP addresses for all servers. In the
case above, Windows was attempting to create a local view, which in essence makes it a
view server for that view.
Back to the INDEX.
cleartool: Error: No permission to perform operation "checkin".
While there could many reasons why a checkin operation fails, this one was caused by
the username of the person checking it out consisting of/starting with a digit.
The UNIX Sysadmin Manual states that a username can contain any combination of
letters, digits, underscores or dashes. However, CC must have a bug in it WRT
this error. Changing to any user other than one starting with a digit solved/circumvented
the problem.
Back to the INDEX.
mount: Error: Operation "rgy_getinfo_by_uuid" failed ("uuid"): ClearCase object not found.
This error occurred on a Solaris 2.6 box running CC 3.2. The cause was that the particular
VOB being mounted had a VOB tag, but was not registered. Simply
registering it solved
the problem.
Back to the INDEX.
derived-object [no config record]
derived object [removed with white out]
These errors show up on the command-line when doing a "ct ls" of a derived object (DO). This is the
result of a "ct rmdo" on an unshared DO.
In the first case, the rmdo command removes the DO configuration record (CR),
but leaves the data container alone. The data container is now a view-private file that
must/can be deleted with a regular rm (or del). However, even though it can no longer be a
candidate for winkin, it is still a useable view-private file.
In the second case, the rmdo command has removed the UNIX reference to the DO
but left the CC view-private reference to it intact. In this case, "touch" the DO and
remove it the normal way; UNIX rm or NT del.
The specific reason why cases result in one or the other error is unknown to me.
Back to the INDEX.
cleartool: Error: view-storage isn't a view: No such file or directory
This occurs when issuing a command, such as catcs, that references a view who's
view-storage is not available for some reason.
Back to the INDEX.
clearmake: Error: Problem starting promote_server for view hostname:view-storage
clearmake: Warning: Unable to promote derived object "DO"
During a build, clearmake knows, via the VOB database, that there is an already built
DO in another view. However, an attempt to promote that DO to be shared in the VOB has
failed. In this case the view-storage of the view owning the original DO was unavailable.
If that view will never be available again, do an rmdo on the specific DO referenced by the
accompanying Warning message.
Back to the INDEX.
Error renaming \\path\TBD(4): File exists.
The View Profile tree is currently in use by other users, and cannot be accessed at this time.
Both of these errors are the result of more than one user attempting to create a View Profile using
the same View Profile Tree. The View Profile Tree is simply a path to where View Profiles are stored
and can be anywhere the user chooses. The View Profile Tree can be reset via ClearCase Home Base ->
Administration -> Control Panel -> Options. Or, you can simply wait until the View Profile Tree is idle.
Back to the INDEX.
cleartool: Error: Cannot get view info for current view: Invalid argument.
This error showed up on NT when attempting a rmtag from the command-line. Do not have
any windows that are in the MVFS drive (usually M:), even if they aren't actually inside
the view whose tag is being removed.
Back to the INDEX.
cleartool: Error: Source "from" and destination "to" are in different versioned object bases.
This error occurs when attempting to create a CC hard symbolic link between VOBs.
Only softlinks (-slink) can be used to link directories in any location or elements across VOBs.
Back to the INDEX.
cleartool: Error: Unable to select "view-private-file", not a selectable object "view private object".
This error shows up when attempting a "ct relocate". The relocate command does not work on view-private
files and will error out if encountering one when it builds its list. Need to move view-private
files somewhere else first. To find all view-private files at or below the path:
# ct lsprivate -invob /path
If you want to simply get rid of all the view-private files, use something like:
# rm -f `ct lsprivate -invob /path`
-or-
# del `ct lsprivate -invob /path`
WARNING: The view-private files may be CHECKEDOUT items or derived objects.
Use the -co, -do and/or -other options to isolate those cases to be handled specially.
Back to the INDEX.
element@@ [eclipsed by checkout]
This occurs when doing a "ct ls -vob_only" and is a normal message. That is, if
a file is CHECKEDOUT and a simple "ls" is done, you will see the view-private version
of the CHECKEDOUT file. If the "ct ls -vob_only" is done, CC will attempt
to show you only files that are versioned elements. However, it can't in the case of
the CHECKEDOUT file because the view-private version of that file is eclipsing it.
Back to the INDEX.
cleartool: Error: Can't create object with group (GID) that is not in the VOB's group list.
cleartool: Error: Unknown group name: group-name
cleartool: Error: Must be a member of new group.
The first error occurs when you attempt to create an object in a VOB in which you are not a member of one
of its groups. In the second error, CC is telling you that the group to which the object is being changed is not
even a recognized group-name on the system. The third error states that you are not a member of the group to
which you are changing an object.
See the discussion in "CC group permissions".
Back to the INDEX.
Unable to get VOB tag registry information for replica uuid "UUID": ClearCase object not found.
This error occurred when attempting a checkout on an NT that was connected
to a UNIX VOB via NFS Maestro. Investigation revealed that there was a checkout
trigger running in the VOB in question whose script was located in another VOB
that was not currently mounted on the NT. Importing the other VOB and mounting
it on the NT alleviated the error.
Back to the INDEX.
cleartool: Warning: Operation "view_change_oid" failed ("element"): Read-only file system.
cleartool: Warning: Operation "view_get_fhandle" failed ("element"): not a ClearCase object.
These errors occur when attempting to check in a UNIX link that was made into an element.
If one imports an entire directory tree into CC and that tree contains some UNIX softlinks, the links
will be made into elements as a part of the clearimport process. However, as part of the clearimport
process, the elements get automatically checked in. The first error occurs if the link is pointing to
an existing element and the second if the link points to a file that is not a versioned object. In both cases,
a copy of the other end of the link gets checked in. However, in the first case, a view-private file called
element.keep is automatically created that is the original link. In the second case, the view-private
link is left alone and the checkedin element is [eclipsed]. If links are needed, use "ct ln" once everything
has been imported.
Back to the INDEX.
cleartool: Error: Unknown host 'hostname':ClearCase object not found
cleartool: Error: Operation "rgy_findbyuuid_entry" failed: ClearCase object not found.
cleartool: Error: View storage directory path not found: "error detected by ClearCase subsystem".
These errors occurred on a network whose registry server has had its name changed.
Go to the registry server and change the old name to the new internal to each registry file.
Stop CC.
# cd registry
Edit each file in turn, perhaps doing them all at once from a Perl script:
# edit file
Restart CC.
Back to the INDEX.
cleartool: Error: Unable to mount: Resource device
This error occurred when attempting to mount a VOB on NT. This happened immediately
following a region change. Because the old VOBs were not unmounted prior to
changing the NT's CC region, CC hung. Attempts at mounting new VOBs or
unmounting the old VOB(s) resulted in the error. A stop and restart of CC did
not help. A reboot of the NT fixed the problem.
When changing a region on NT, stop all views and unmount all VOBs first.
If this is done, no restart of CC or the system is necessary.
Back to the INDEX.
cleartool: Error: Can't pick element type from rules in "magic-PATH".
If the element being created doesn't already exist as a view-private
file, create an empty view-private file first.
In NT Explorer:
File -> New -> file
In UNIX:
# touch file
If the element being created already exists and you still get this
error, add rule for the file to an appropriate magic file. See cc_magic in
the CC Reference Manual.
Back to the INDEX.
text_file_delta: Error: "filename" is not a 'text file': it contains a '\000'.
cleartool: Error: Type manager "text_file_delta" failed create_version operation.
These errors occur when attempting to check in an ascii file that has a binary
character emebedded in it somewhere. Simply remove the offending character. In Perl,
use code similar to the following:
open(FILE,"filename");
while (<FILE>) {
print if $_ =~ /\0/;
}
close(FILE);
exit;
NOTE: A Perl5 executable called "Perl" comes bundled with CC 3.2. In CC 3.2.1+,
the executable is called "ccperl". Both are available on UNIX & NT and both live in
atria-home/bin.
Back to the INDEX.
cleartool: Error: More than one version with label of type "label-type".
This error occurs when the following command is run on an element that has the
specified label attached to more than one of its versions.
# ct mkbranch -ver label branch element
The mkbranch subcommand needs to create a branch from a unique version. In this case,
the element had two instances of the label. Simply don't use "-ver label"
and instead specify element@version.
Back to the INDEX.
cleartool: Error: The VOB storage directory "VOB-storage" was not found.
cleartool: Error: Could not register gpath in the prefix map.
These errors occur when attempting to mount a VOB (first msg) or start a view
(second msg) from the CLI for a VOB and/or view whose server has either had its name
changed or is not available. The GUI error message is null. That is, a CC error box
pops up, but there is no error message.
If the server that owns the view/VOB has had its name changed, the view and VOB
global paths will have to be reregistered and retagged.
# ct unregister -view -uuid UUID
# ct rmtag -view view-tag
# ct register -view view-storage
# ct mktag -view -tag view-tag view-storage
The steps are synonymous for VOBs.
Back to the INDEX.
cleartool: Error: Unable to find replica in registry for VOB with object ID:"UUID"
cleartool: Error: Unable to determine administrative VOBs of VOB "vob-tag".
cleartool: Error: Unable to locate versioned object base with object id: "UUID".
cleartool: Error: Unable to search for process guards
cleartool: Error: Unable to remove hyperlink "hyperlink-id".
? <- <object not available>
The above set of errors occurred when attempting to remove an AdminVOB hyperlink.
In this case, the administrative VOB was no longer available. The first and third errors
occurred when creating a stream in a PVOB. The component VOB was the AdminVOB and one end of
a RelocationVOB for a VOB that was no longer available. The last error message appears if one
does a "ct describe" on the offending object.
In general, these errors can occur any time a hyperlink is "broken".
For example, if a MetaData type is defined in an admin VOB and is used/applied in a
client VOB, a GlobalDefinition hyperlink is connected between the type definition in the admin
VOB and the one in the client VOB. If the client VOB is subsequently removed, you won't be able to
remove the offending, globally defined MetaData without running the checkvob command on it.
Normally the GlobalDefinition hyperlink can be removed if the globally defined MetaData type
definition is replaced with a local definition, but not in this case.
In these cases, the following types of commands will
prompt for any dysfunctional hyperlinks and ask if you want them removed.
# ct checkvob -hlinks vob:vob-tag
# ct checkvob -hlinks brtype:branch-type
# ct checkvob -hlinks lbtype:label-type
Back to the INDEX.
cleartool: Error: Operation "rgy_getstring_from_entry" failed: ClearCase object not found.
This error occurs when running "ct rmview -uuid view-uuid" in a VOB when the
view's storage area has been removed without using CC commands. This error is to be expected.
When you run "ct rmview -uuid", CC removes references to the VOB from the view's database and
then removes references to the view from the VOB's database. However, in this case the view's database
no longer exists. The error message is then followed by a message stating that the VOB was
cleaned up successfully. The upshot is that this error is to be expected if the view storage
is not available.
Back to the INDEX.
The network path was not found.
cleartool: Error: Could not register gpath in the prefix map.
On NT, the above errors occur when attempting to mount a VOB or start a
view whose storage area is unavailable for some reason. The second error
occurred when attempting a startview from the CLI. The first occurred
when attempting a simple "dir storage-area" from the CLI. One should
be able to see the contents of the storage area via the registered path
independent of CC.
If the server trying to be reached is available (ping) and the drive on which
the storage areas live is properly shared, try going to Control Panel ->
Network -> Protocols -> TCP/IP Protocol (Properties...) ->
WINS Address and set "Enable DNS for Windows Resolution".
NOTE: In NT, from the GUI, the above condition will result in
a CC error box that has no error message in it.
Back to the INDEX.
mvfs: Error: view shtest - all licenses in use!
This occurs if your license expires while in a view and you aren't
able aquire a new one. Use
clearlicense
to release a license or wait until one becomes available. Alternatively, have the
CC Administrator purchase more licenses.
Back to the INDEX.
element [loaded but missing]
This occurs in a snapshot view when the loaded file has been deleted. If the element is
checkedout, simply do an uncheckout. If the element is checkedin, update the view.
This also occurred when running a snapshot view remotely. That is, NT ClientA sets up
a snapshot view and ClientB accesses that snapshot view via an NT share. The checkout of an
element from ClientB works ok, but a checkin or uncheckout leaves the file [loaded but missing].
Unknown cause or solution. According the CC 3.2.1 Using Snapshot Views manual(pg 80), this
configuration should work fine.
This is analogous to a dynamic view's
[checkedout but removed].
Back to the INDEX.
cleartool: Error: The feature level of at least one replica is unknown; the VOB family feature level can not be raised.
cleartool: Error: Unable to raise the VOB family feature level - error detected by ClearCase subsystem
These errors occur when attempting a "chflevel -family" and there is a member of the family that
is not up to the level to which you are attempting to raise the family. See
chflevel. If each self-mastering
replica has successfully raised its own feature level and all those VOBs have sync'ed back with the
VOB attempting the "chflevel -family" and you still get the error message, check "mt lsreplica". There
may be a replica name known to the VOB family that is not really a replica. That is, there may be a
replica name just hanging out there that can simply be deleted with "mt rmreplica".
However, you will always get this error message if the replica synchronization
is unidirectional. That is, if the sync packets only go in one direction, the current VOB
will never know about the feature level of the other replicas. In that case, you must
use the -override option. Just be sure that the chflevel command to the new level
has already been run manually on the remote site's replicas.
Back to the INDEX.
Error copying file "albd.z" Access is denied.
This error occurs when attempting to overwrite a Network Release Area. When the previous
setup of the release area completed, it set files to read-only to protect them.
Rational recommends using separate release areas for separate releases. However, if you must
overwrite the existing release area, simply go there and change the files to be writeable.
Back to the INDEX.
element [disputed checkout, checkedout but removed]
This happened as a result of the following events. 1) Created cleartool hardlink to
another element. 2) Checkedout the new end of the hardlink. 3) Checked in the parent directory
of the new end of the hardlink. 4) Checkedout the parent directory of the new end of the hardlink.
5) Did "ct rmname" on the checkedout new end of the hardlink. This left the other end with the
error message. However, attempts to reproduce the error to better understand it failed. That is,
I could only create the standard [checkedout but removed] error, which is corrected by simply
doing an uncheckout on it. All attempts to get it say "disputed checkout" again failed.
Back to the INDEX.
Error: failed to load DLL ntadmin.dll: -1
This error occurred when attempting to apply patches to a release area that has just
been upgraded to CC 3.2. The patch executables need a dll that doesn't currently
exist on the system and won't until after the 3.2 install. So, to get around this error,
do the install without any patches on the machine on which the release area resides.
Once the install has completed, the patches can be applied to the release area without error.
Then, simply rerun the install from the patched release area.
Back to the INDEX.
ERROR: Your CWD must be the install sub-directory within the patch sub-directory of a release area.
CC UNIX patches cannot be applied directly to the install, they must be applied
to a release area from a sub-directory within the release area. For more notes on installing
CC patches, see
./cc_howto.html#MISC31.
Back to the INDEX.
cqconfig: Can't create checkin trigger!
This error occurred when attempting to integrate CC with CQ on an NT connected to
UNIX VOBs via NFS Maestro. Both machines were running CC 4.0, patched to the latest level,
and the UNIX side had the "ClearQuest Integration with ClearCase" installed. When
attempting to integrate the two tools from the NT side via the "ClearQuest Integration
Configuration" wizard in the ClearCase Administration menu, the error only occurred if
the VOB was on the UNIX side. That is, NT VOBs integrated with no problem. The interop
connection was verified independent of the integration. That is, I was able to create
and work on UNIX VOB elements via the NT.
The problem was that the usernames were not matched between NT and UNIX.
While normal operations work ok without a one-to-one match in usernames, to set up the
integration from the NT side, your interop connection needs to log you into the UNIX
side as the VOB's owner. Once the ownership was straightened out, the integration worked
as expected.
Back to the INDEX.
cleartool: Error: There are no generated data sources available for storage dir "vob-storage"
on host "hostname".
cleartool: Error: Failed to get space info for vob "vob-tag".
This error occurs when attempting to use the
space command in an empty VOB.
It simply means that there is nothing to report. Ignore it.
Back to the INDEX.
cleartool: Error: Trouble protecting versioned object base "vob-tag".
This error occurs when attempting to modify protections on the VOB itself via
the "protectvob" command. You must be VOB owner or root to change VOB protections.
Back to the INDEX.
cleartool: Warning: Moved private data from "file" to "file.keep" so it won't eclipse element.
A new element can be created if a view-private file of the same name does or does not exist.
In the case where there is an existing view-private file of the same name as the new element,
it depends on the mkelem options used as to whether that view-private file's contents will
be copied to the new element. For instance, if the -ci option is used, CC creates a new empty
element, checks-out the 0'th version, copies the view-private data into the checkedout version and
then automatically checks it in. However, if the -nco option is used, CC will create the new
empty element but does not check it out. So, if the element isn't checked out, there is no way
for the view-private file's contents to be copied over. If CC simply left it at that, the
view-private file would eclipse the source controlled version (which is normal), hence the
warning message.
Back to the INDEX.
Unable to assign drive to view: error1202.
This error occurs when you attempt to map a view to a drive letter that is in
use. Normally, drive letters that are in use are not even presented to you as options.
However, on NT, CC 4.0 UCM up to at least patch 9, defaults to drive letter Z
even though it is in use when creating views via the Project Explorer. Simply choose
a letter other than Z, as it appears that this bug only applies to Z and the other
drive letters it presents you are ones not being used.
Back to the INDEX.
clearexport_ccase: Error: Unable resolve pathname "view-private-file".
The clearexport_ccase command only works on versioned objects. If there are any
view-private files in the tree selected for copy, they will each generate the error message.
Simply ignore the error.
Back to the INDEX.
cleartool: Error: Unable to unmount: error detected by ClearCase subsystem
This error occurred when attempting to unmount a VOB on NT in CC 4.0. No windows
were inside the VOB. A restart of CC failed to clear the error. Since this was a private
VOB, it wasn't remounted upon reboot. Cause of the error unknown.
Back to the INDEX.
cleartool: Error: vob-tag is not a registered VOB tag.
After running "rgy_check -vobs" on an NT running CC 4.0 and seeing that a VOB tag had
no storage associated with it, this error occurred when attempting a rmtag. Inspection of the
ccase-home-dir\var\rgy\vob_tag file revealed that the tag was in a region other
than the one to which the server was pointing. Use of the -region option to rmtag solved the problem.
Back to the INDEX.
Error checking in 'element'.
Trigger "cq_ci_trigger" has refused to let checkin proceed.
There can be many reasons why cq_ci_trigger refuses the checkin.
This error only shows up when CC is integrated with CQ in a non-UCM manner via the
ClearQuest Integration Configuration wizard in the ClearCase Administration menu.
1) Depending on the policy you've set up, CC will require a bug number when to
complete the operation. If the window that pops up requesting a CQ record ID be
associated with the CC checkin and you click OK without explicity clicking the
Associated button first (or you hit the Cancel button), the error will result.
2) If you've run the ClearQuest Integration Configuration wizard in the ClearCase
Administration menu, but the CQ database has not been configured to use the CC
integration, the error will result. See
integrating CC/CQ w/o UCM
for details.
Back to the INDEX.
Error: albd_server must run in the clearcase group
This error can occur on an NT if your albd_server login (most likely clearcase_albd)
is not attached to any group or the group that CC thinks the albd_server lives in is
incorrect. This can happen if one has changed the name of the clearcase_albd user and its
group. If, after changing the username and password in the Atria Location Broker service,
you still get the error message, make sure the NT registry has been properly updated.
Start regedt32 and check the following key:
HKEY_LOCAL_MCHINE->SOFTWARE->Atria->ClearCase->CurrentVersion:ClearCaseGroupName
Be sure to reboot the machine after manually editing the registry.
Back to the INDEX.
clearimport: Error: Newer version in VOB blocks import of version "version".
This error occurred when attempting to update existing elements using the
clearexport_*/clearimport commands. If the import is done by the VOB owner, the modification
dates of the files are unchanged. If the import is done by the VOB owner or any other user
and the -nsetevent option is used, the modifications date/time of each element is set to
the time of import. If one tries to do a subsequent import of files with the same names
that have modification dates earlier than those checked into the VOB, the error will occur.
In short, clearimport will not update an existing element with a file with an older
modification time.
The following scenario can cause that to happen. Somebody sends you a set of files
in a directory structure for import into a VOB. Before you get around to importing them,
they send you an updated version of that directory tree. Now, you could "merge" the two
outside CC and attempt to determine which files are different, but it's much easier to
simply import the first version and then simply update the changed files with new versions.
So, you import the first set of files using the -nsetevent option, perhaps because you are
not VOB owner, and the modification times of the those files are reset on import. Now, you
go to import the second set of files to update the VOB, but the modification times of that
set are older than the ones now in the VOB. Error.
To get out of this situation you can do one of the following. 1) Delete the elements
in the VOB and redo both imports as the VOB owner without using the -nsetevent option.
That way the modification times stay in the correct order.
2) Manually determine which files have changed and update those ones by hand in the VOB.
On NT, WinDiff.exe can diff two directory structures for you. On UNIX, do an "ls -lR" of
each tree into separate files and use diff.
Back to the INDEX.
Runtime Error! Program:C:\PROGRA~1\RATIONAL\CLEARQ~1.0\CQINTS~2.EXE
R6025 - pure virtual function call
This error occurred with CC integrated with CQ using UCM while checking out an element
and associating a ticket with that activity. However, further fiddling could not reproduce
the error. After a second attempt, the ticket was updated correcty and there seemed to be
no lasting affects. Reason for the original error unknown. What's curious is that the error
mentions CLEARQ~1.0, but this system was running CQ 2.0.
Back to the INDEX.
rcptcp_create: RPC: Remote system error - [WINSOCK] Connection refused
clearlicense: Error: unable to contact albd_server on host 'hostname'
NPLogon /xdr/albd: Error: Unable to contact albd_server on host 'hostname'
The first two errors occurred when running clearlicense between a CC 4.0 client and
CC 3.2.1 license server. The first attempt at reaching the license server used
TCP/IP. There is a known bug (CMBU 44216) that prevents this from happening.
However, if TCP fails, CC will immediately try UDP, which then succeeds. So, for
the time being, Rational considers this bug to be cosmetic and has given it low
priority. Simply ignore it.
However, these error messages, including the third, can also occur if the
albd service on the specified license service is down for some reason.
Back to the INDEX.
can't unload the module: Device busy
This error occurred on a UNIX system that had crashed due to overheating.
After the system was brought back up, there were problems with getting the VOBs remounted.
All attempts failed. Attempts to shutdown and restart CC resulted in the error message
when it gets to the point saying "Unloading mvfs...". Unfortunately, all attempts to
recover the system short of a reinstall failed.
Due to the nature of this problem, a simple reinstall of CC over the old one, as if
doing an upgrade, is not sufficient. Corrupt files may have the same modification date
and not get properly replaced.
The deinstall won't go unless it can shutdown CC. However, CC won't shutdown
properly due to the error message. So, you must mv the /etc/init.d/atria file to a different
name and restart the computer. When it comes back up, CC won't be started. Once that
is complete, you may procede with the deinstall. Even though the deinstall will make
a copy of the registry, you should probably make a copy of /var/adm/atria yourself just to be safe.
Note that a patch in CC 2002 and 2003 changed the name of the startup file to
/etc/init.d/clearcase.
Once the reinstall is complete, all should be fine.
Back to the INDEX.
view_server(PID): Error: Unable to construct cleartext for object "element" in VOB "host-path": error detected by CLearCase subsystem.
view_server(PID): Error: Type manager "type-manager" failed construct_version operation
text_file_delta: Error: Unable to open file "UNC-path-to-data-container": Permission denied
text_file_delta: Error: Unable to open file "UNC-path-to-data-container": Invalid argument
mvfs: ERROR: view=view-tag vob=vob-tag - ClearCase vob error see view_log on host hostname for more info
cleartool: Warning: Version checked in is not selected by view.
The first three errors appeared in the NT Event Viewer and view logs. The fourth was a warning
in the NT Event Viewer. The fifth error appeared as a pop-up dialog when the error
occurred. The sixth appeared at the time of the error on the CLI.
These errors occurred in an NT view accessing a UNIX VOB via Syntax TAS. One was able
access the VOB normally for all operations except checkin. One could add files to source
control as well.
The procedure for configuring TAS was followed exactly and rechecked. However, even though
one maps the NT clearcase_albd user to the UNIX vobadmin VOB owner, one still needs to add
vobadmin as a recognized Totalnet User. That is, the procedure is inadequate in that it
assumes the map is sufficient for TAS to recognize vobadmin. After adding vobadmin as a
user, all was well. I am unable to explain why one could add files to source control without
issue but had trouble checking them in.
Back to the INDEX.
view_server.exe (PID): Error: Can't determine if the file system on which "." lives supports acls.
The drive on which a VOB or view's storage lives must give Full Control to the SYSTEM.
Back to the INDEX.
msdostext_mode: Error: Operation "ver_unformat_cltxt" failed: ClearCase object not found
This error occurs when attempting to convert a VOB to interop with the msdostext_mode
command. It is an indication that permissions are not sufficient. You need to be the VOB owner
or Administrator/root to run the conversion. If the error persists and you are the VOB owner,
it's possible that there are UIDs in the VOB that no longer map to an active user. In that case,
attempt it as root. Also, try running "ct protect -chown vob-owner -r" on the VOB's files.
Also, consider running "ct protectvob -chown vob-owner -chgrp vob-owner's-group"
on the vob-storage-area. Once the permissions are sorted out, the command should complete ok.
Back to the INDEX.
The instruction at "reference_number" referenced memory at "memory_location". The memory could not be "read".
Reinstall and reboot had no affect. No solution at this time.
Back to the INDEX.
Unable to login: username or password is incorrect
This error occured when attempting to access CC via the web interface just after configuring
it on RedHat LINUX 7.0. LINUX MD5 and shadow password defaults are selected on installation of
RedHat LINUX and need to be deactivated. As root, from the CLI, run authconfig. Clear the check
boxes that enable MD5 encryption and shadow passwords.
NOTE: Users that already have passwords on the system need to run "passwd" to reset
them. That is, they need to be reencrypted, this time without MD5 encryption.
Back to the INDEX.
cleartool: Error: Unable to access database (format too old): "vobtag".
This error occurred after upgrading CC to a version that requires a reformat of the
VOBs. This is true when upgrading to 4.x and accepting the new extended VOB format (schema 54).
One should have backed up the VOBs just prior to the upgrade. However, if not, the next step
would be to back them up just prior to the reformatvob. Unfortunately, if the upgrade is already
done, the VOBs cannot be locked due to the above error. If you've gotten to that point,
there is no recourse but to simply run the reformatvob without backing them up.
Back to the INDEX.
vob_snapshot_setup encountered an ERROR in modparam: Vob tag is invalid
This error occurred while setting up VOBs for nightly database snapshots.
The VOB in question was tagged in the same region as the other VOBs, but its storage
area was on a different server. The VOB storage area must be on the server you are
sitting in front of when the vob_snapshot_setup is run.
Back to the INDEX.
Error copying file "albd_spec.rgy". Access is denied.
Error copying file "albd_spec.rgy". The process cannot access the file because it is being used by another process.
These errors occur when attempting to simply rerun the siteprep.exe on NT to change
a parameter, such as region name. These errors are new in CC 4.2. That is, one could simply
rerun the site prep anytime without incident in CC versions prior to 4.2.
The first error occurs when making the first attempt at rerunning the site prep.
The second error occurs if you remove the "Read Only" status of the mentioned file and attempt to
run the site prep again.
The file is being read by siteprep.exe, which means it has the file open for read
and therefore cannot write to it. If desired, run the siteprep.exe directly from the cdrom
and set all the parameters. Or, if a simple change is needed, just open sitedefs.dat and
edit the parameter manually.
Back to the INDEX.
cleartool: Error: Checked out version, but could not copy data to "filename" in view: unknown error in VOB.
This occurred in a UNIX view using CC 4.2. All attempts to clear the problem, such as restarting
the view_server process, failed. However, for unknown reasons, after setting to a different view that
had the same config_spec, checking out the file and immediately unchecking it out cleared the problem
in the first view.
Back to the INDEX.
cleartool: Error: Unable to determine absolute pathname for "\vobtag" - Permission denied
cleartool: Error: Unable to access "\vobtag": Input/output error.
These errors occurred when attempting access a VOB on Windows using CC 4.2. For unknown reasons,
stopping and restarting CC cleared the errors. Note, the first access to the VOB after restarting
CC took awhile.
Back to the INDEX.
vobsvr_contact call failed: RPC: Unable to receive; errno = [WINSOCK] Connection reset by peer
This error occurred when attempting to get a description of a VOB on a Win2k system running
CC 4.2. A reboot of the system cleared the problem. Unknown reason for the error :-(.
Back to the INDEX.
Could not decrypt the Server Process password in site defaults file "path\sitedefs.dat".
This error occurred when attempting to run a siteprep in an existing Windows CC release area.
For unknown reasons, the sitedefs.dat file that saves the siteprep data was corrupt. Simply move
the existing sitedefs.dat file to .bak and let the siteprep create a new one.
Back to the INDEX.
cleartool: Error: View tag "": ClearCase object not found
cleartool: Error: Operation "view_get_handle_by_tag" failed: error detected by ClearCase subsystem.
cleartool: Error: No view context available
This error occurs when attempting to get CC information that requires a view context
and you are not currently in a view. For example, if you are sitting on "C:\" and run
"ct lsactivity", since activities are UCM stream/view dependent, you will get an error
that the view is unknown. Either change your directory into a drive letter associated with a view,
or supply an appropriate argument, such as "ct lsactivity -view <view-tag>".
Back to the INDEX.
mount: Error: Unable to get hostinfo for hostname
Trouble mounting the viewroot "/view" (16:1)
Trouble setting MVFS kernel log file to /var/adm/atria/log/mvfs_log (2:1)
cleartool: Error: The MVFS file system is not installed or not loaded, or the 'viewroot' is not mounted or is inaccessible: not a ClearCase object.
These errors occurred at the end of a CC 5.0/2002 install on Solaris 8. The install seemed
to complete properly, but CC was unable to start itself. The problem was a mismatch in what
the server thought its name was. The commands "hostname" and "uname -a" and the /etc/hosts
file all reported the same name, but the /etc/nodename file had a different name. Editing
the nodename file directly and rebooting seemed to have no affect. A complete deletion of
the nodename file caused the server to have an "unknown" name. Adding the nodename back
with the correct name solved the problem.
Back to the INDEX.
Error Description: timed out trying to communicate with ClearCase remote server. Error Code: 1004
This error occurred when attempting to run a report from within the CC Report Builder
on a stand-alone Windows box. The machine can ping itself by name. The albd service is up.
The PVOB is and components are accessible via other utilities. Unknown reason for the error.
Back to the INDEX.
RCCO1.0: Error: Unable to lookup "vobs": No such file or directory.
This error occurred in the RCCO interface when attempting to Update a single
element in a view. This was done in a view that had never been used before.
When a checkbox for an element is selected and the Update button is clicked,
a screen appears confirming the download. Because the files have never been loaded
into the view, you must select Load instead of the default Update. This will
create a directory in your view on your local box called "vobs" that has inside of
it the component and any downloaded elements.
Back to the INDEX.
cleartool: Error: Failed to record hostname "view-server" in storage directory "remote-local-path\vws". Check that root or the ClearCase administrators group has permission to write to this directory.
This error occured on a Windows client when attempting to create a view on
a view server. Cause unknown. Solution unknown.
Back to the INDEX.
ClearCase daemons: Albd server startup error(4:1)
This error occurred when attempting to start CC on a Unix box. This happened after
a rename of the server. An entry in error_log indicated that there was a problem with the
view_tag file. The registry files had been edited by hand as part of the server rename to
avoid the numerous rmtag, unregister, mktag, and register commands. However, an erroneous
character was placed on a line by itself at the end of the file, as indicated by the error
message in the error_log. A simple cleanup of that line fixed the problem.
I have since written a script to run all the CC commands properly when a view or
VOB server has been renamed.
Back to the INDEX.
cleartool: Error: Checked out version, but could not copy data to "element" in view: Operation not permitted.
This is a permission issue. The group on the element itself was
not in the VOB's group. A "ct protect" to change the group of the element solved
the problem.
Back to the INDEX.
/lib/modules/fs/mvfs.o: unresolved symbol ...
The "unresolved symbol" errors occured after installing CC on a Linux
box. These errors caused MVFS to fail. You need to recompile mvfs.o in a
configuration that works for your system.
The particular config file chosen in step (2) will deterime whether or
not mvfs will compile and work when atria is restarted. That is, the actual
.config file shown in step (2) is the one that solved my problem, but may not
be the one you need to get mvfs to recompile and restart without errors.
The following steps must be performed as root. No kernel rebuild or reboot
necessary.
1) cd /usr/src/linux/configs
2) cp kernel-2.4.7-i686-smp.config ../.config
3) cd /var/adm/atria/mvfs/linux*
4) make
5) /etc/rc.d/init.d/atria stop
6) /etc/rc.d/init.d/atria start
Back to the INDEX.
db_obj_resolve_name_V3: RPC: Unable to receive; errno = Connection reset by peer
db_abort_trans_V3: RPC: Unable to receive; errno = Connection reset by peer
These errors occurred while running clearfsimport using "-preview" and "-mklabel"
at the same time. This is a known defect that is supposedly fixed in CC 2003.06.00.
If you want to run with -preview, leave off the -mklabel option. When you want to run
it for real, leave off the -preview option and insert the -mklabel option.
Back to the INDEX.
Segmentation fault
This error occurred when starting xclearcase (2002.05.00, patch 26) and
some other GUIs on RedHat 9 Linux. The out-of-the-box LANG environment variable
setting is "en_US.UTF-8". This needs to be reset to "en_US" or "en_US.iso885915".
Each user can "setenv LANG en_US". Unsure how set the LANG for the whole system.
Back to the INDEX.
Couldn't mount VOB: vobtag
This error occured on a Windows box running CC 2002. The VOB was one that
was removed. It's name is stuck in the registry as one that is to be remounted
after reboot. See Enable/disable VOB auto-remounting after reboot.
Back to the INDEX.
Premature end of script headers: ccweb.exe
Updated: 09/19/06
This error occured when attempting to access ccweb after a new install of CC 7.0
on Windows XP.
Solution unknown.
Back to the INDEX.
text_file_delta: Error: Can't create temporary file: Permission denied
Type manager "text_file_delta" failed create_version operation.
Updated: 03/28/07
A possible cause of this error is an undefined temp directory.
Create a system environment variable called "TMP" and point it to a
temp directory, such as C:\temp or /tmp.
Back to the INDEX.
Return to the home page .
This page last modified: 02/24/2009