rmdo

Removes a derived object from a VOB

Applicability

Product

Command type

VersionVault

cleartool subcommand

Platform

UNIX

Linux

Windows

Synopsis

  • Remove individual derived objects:
    rmdo do-pname ...
  • Remove collections of derived objects:
    rmdo { –a/ll | –zer/o } [ –bef/ore date-time ]
    [ –sin/ce date-time ] [ pname ... ]

Description

The rmdo command deletes one or more derived objects (DOs). Use rmdo to remove DOs (for example, damaged DOs or DOs that were built incorrectly) so that other users do not use them inadvertently.

Note: This command does not apply to snapshot views.

The details of the removal process depend on the kind of DO (use lsdo –long to determine the kind of DO):

  • For a shared derived object whose data container is in VOB storage, rmdo deletes the entry in the VOB database and also deletes the data container file from one of the VOB's DO storage pools.
    Important: If you need to remove a shared DO, use lsdo –long to identify the views that reference the DO. Ask the owner of each view to remove the DO from the view with an operating system command or by running make clean or an equivalent command. If the DO is not removed from the referencing views before you use rmdo, error messages appear. For example, when users try to access the DO from the referencing views, the view_server logs VOB warnings. Also, you may see INTERNAL ERROR messages in the VersionVault error_log file; these messages are generated when clearmake or an OS-level command tries to access the DO. The derived object's name is removed from the directory by the OS-level access; thus, subsequent accesses return not found errors.
  • For an unshared derived object whose data container is in view-private storage, rmdo deletes the entry from the VOB database, but does not delete the data container from view storage. The data container is an ordinary file that can still be listed, executed, and so on, but it cannot be a candidate for configuration lookup. The ls –long command lists it with a [no config record] annotation. To delete the data file, use an operating system command.
  • For a nonshareable derived object, which does not have an entry in the VOB database, rmdo converts the DO into an ordinary view-private file. To delete the file, use an operating system command.

In each case, rmdo also deletes the associated configuration record if it is no longer needed. Both of the following conditions must be true:

  • No other sibling DO (created in the same build script execution) still exists.
  • The DO is not a build dependency (subtarget) of another DO that still exists.

rmdo does not delete DO versions. To delete a DO that has been checked in as a version of an element, use rmver.

Scrubbing of derived objects

VersionVault includes a utility, scrubber, that deletes shareable DOs. scrubber deletes the entries in the VOB database and (for shared DOs) the data containers in the VOB's storage pools. By default, the VersionVault scheduler runs scrubber periodically. See the schedule reference page for information on describing and changing scheduled jobs.

Each DO pool has scrubbing parameters, which you can modify with the mkpool –update command.

Restrictions

Identities

You must have one of the following identities:

  • DO owner
  • DO group member
  • VOB owner
  • root (UNIX and Linux)
  • Member of the VersionVault administrators group (Windows)

To delete a shared DO, you must have one of the following identities:

  • VOB owner
  • root (UNIX and Linux)
  • Member of the VersionVault administrators group (Windows)

Locks

An error occurs if one or more of these objects are locked: VOB, pool.

Mastership

(Replicated VOBs only) No mastership restrictions.

Options and arguments

Specifying criteria for deleting derived objects

Default
Deletes at most one DO for each file name specified with command arguments. A file name with a DO ID (for example, hello.o@@2006-03-24T11:32.412) specifies exactly which DO to delete. A standard or view-extended pathname specifies the DO that appears in the view.

To determine the DO IDs of derived objects, use lsdo.

–a/ll
Deletes all DOs at a given pathname, regardless of the view in which they were created or appear. (Be careful when deleting DOs—see the Description section.)
–zer/o
Similar to –all, but deletes only those DOs with zero reference counts.
-bef/ore date-time, –sin/ce date-time
Deletes DOs at the specified pathname that were created before or since the specified date and time.

The date-time argument can have any of the following formats:

date.time | date | time |now where:

date

:=

day-of-week | long-date

time

:=

h[h]:m[m][:s[s]] [UTC [ [ + | - ]h[h][:m[m] ] ] ]

day-of-week

:=

today |yesterday |Sunday | ... |Saturday |Sun | ... |Sat

long-date

:=

d[d]–month[–[yy]yy]

month

:=

January |... |December |Jan |... |Dec

Specify time in 24-hour format, relative to the local time zone. If you omit the time, the default value is 00:00:00. If you omit date, the default is today. If you omit the century, year, or a specific date, the most recent one is used. Specify UTC if you want to resolve the time to the same moment in time regardless of time zone. Use the plus (+) or minus (-) operator to specify a positive or negative offset to the UTC time. If you specify UTC without hour or minute offsets, Greenwich Mean Time (GMT) is used. (Dates before January 1, 1970 Universal Coordinated Time (UTC) are invalid.)

Specifying derived objects

Default
With –all or –zero, the default is to list all DOs in the current working directory. If you do not specify one of these options, you must supply at least one argument.
do-pname ...
Pathnames of one or more individual DOs. A name with a DO ID, such as foo@@10-Nov.10:14.27672, specifies a particular DO, irrespective of view. An operating system pathname or view-extended pathname specifies the DO that appears in a view.
pname ...
(use with –all or –zero) One or more standard or view-extended pathnames, each of which can name a file or directory:
  • A file name specifies a collection of DOs built at the same pathname.
  • A directory name is equivalent to a list of all the file names of DOs built in that directory, including file names that do not currently appear in the view (perhaps after running make clean).

Examples

The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you might need to use different quoting and escaping conventions.

The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you might need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.

  • Delete the derived object hello.obj@@2006-03-24T11:32.412.

    cmd-context rmdo hello.obj@@2006-03-24T11:32.412
    Removed derived object "hello.obj@@2006-03-24T11:32.412".

  • Delete all derived objects named hello in the current working directory.

    cmd-context rmdo –all hello.exe
    Removed derived object "hello.exe@@2006-03-24T14:16.178".
    Removed derived object "hello.exe@@2006-03-23T19:25.394".

  • Delete all zero-referenced derived objects in the hworld directory.

    cmd-context rmdo –zero hworld
    Removed derived object "hworld/hello.o@@2006-03-23T20:42.373".
    Removed derived object "hworld/hello.o@@2006-03-23T20:36.228".
    Removed derived object "hworld/hello@@2006-03-23T20:42.382".
    Removed derived object "hworld/hello@@2006-03-23T20:36.234".
    Removed derived object "hworld/util.o@@2006-03-23T20:42.376".
    Removed derived object "hworld/util.o@@2006-03-23T20:36.231".