2005-12-08 12:14:33 +00:00
|
|
|
=head1 NAME
|
|
|
|
|
2007-11-11 22:54:56 +00:00
|
|
|
vos_rename - Renames a volume
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
=for html
|
|
|
|
<div class="synopsis">
|
|
|
|
|
|
|
|
B<vos rename> S<<< B<-oldname> <I<old volume name>> >>>
|
2009-10-08 18:31:00 +01:00
|
|
|
S<<< B<-newname> <I<new volume name>> >>>
|
|
|
|
S<<< [B<-cell> <I<cell name>>] >>>
|
|
|
|
[B<-noauth>] [B<-localauth>]
|
2013-06-20 23:45:05 +01:00
|
|
|
[B<-verbose>] [B<-encrypt>] [B<-noresolve>]
|
|
|
|
S<<< [B<-config> <I<config directory>>] >>>
|
|
|
|
[B<-help>]
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2009-10-08 18:31:00 +01:00
|
|
|
B<vos ren> S<<< B<-o> <I<old volume name>> >>>
|
|
|
|
S<<< B<-ne> <I<new volume name>> >>>
|
2013-06-20 23:45:05 +01:00
|
|
|
[-c <I<cell name>>] [B<-noa>] [B<-l>] [B<-v>] [B<-e>] [B<-nor>]
|
|
|
|
S<<< [B<-co> <I<config directory>>] >>>
|
|
|
|
[B<-h>]
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2006-03-01 05:02:29 +00:00
|
|
|
=for html
|
|
|
|
</div>
|
|
|
|
|
2005-12-08 12:14:33 +00:00
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The B<vos rename> command changes the name of the read/write volume
|
2005-12-08 12:14:33 +00:00
|
|
|
specified with the B<-oldname> argument to the name specified with the
|
2005-12-09 14:48:56 +00:00
|
|
|
B<-newname> argument. The names of the read/write's read-only copies and
|
|
|
|
backup copy, if any, change automatically to match.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
After issuing this command, remember to correct any mount points that
|
|
|
|
refer to the old volume name, by removing the old mount point with the
|
|
|
|
B<fs rmmount> command and creating a new one with the B<fs mkmount>
|
2005-12-08 12:14:33 +00:00
|
|
|
command.
|
|
|
|
|
|
|
|
=head1 OPTIONS
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
vos: fix name availability check in vos rename
The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.
The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.
Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed. The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.
Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.
Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.
Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.
Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.
Change-Id: Ibb5dbe3148e9b8295347925a59cd7bdbccbe8fe0
Reviewed-on: https://gerrit.openafs.org/13720
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2019-07-22 20:20:24 +01:00
|
|
|
=item B<-oldname> <I<old volume name or id>>
|
2005-12-08 12:14:33 +00:00
|
|
|
|
vos: fix name availability check in vos rename
The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.
The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.
Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed. The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.
Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.
Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.
Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.
Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.
Change-Id: Ibb5dbe3148e9b8295347925a59cd7bdbccbe8fe0
Reviewed-on: https://gerrit.openafs.org/13720
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2019-07-22 20:20:24 +01:00
|
|
|
Is the current name or numeric id of the read/write volume to be renamed.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
=item B<-newname> <I<new volume name>>
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
Is the desired new name for the volume.
|
|
|
|
|
vos: fix name availability check in vos rename
The UV_RenameVolume() function first updates the volume name in the
VLDB, then read-write volume header and backup volume header, and
finally all of the read-only volume headers. If this function is
interrupted or a remote site is not reachable, the names in some of the
volume headers will be out of sync with name in the VLDB entry.
The implementation of UV_RenameVolume() is idempotent, so can be safely
called with the same name as in the volume's VLDB entry. This could be
used to bring all the names in the volume headers in sync with the name
in the VLDB.
Unfortunately, due to the check of the -newname parameter, vos
rename will not invoke UV_RenameVolume() when the name in the VLDB has
already been changed. The vos rename command attempts to verify the
desired name (-newname) is available before invoking UV_RenameVolume()
by simply checking if a VLDB entry exists with that name, and
incorrectly assumes when a VLDB entry exists with that name it is an
entry for a different volume.
Change the -newname check to allow vos rename to proceed when name has
already been set in the VLDB entry of the volume being renamed. This
allows admins to run vos rename command to complete a previously
incomplete rename operation and bring the names in the volume headers in
sync with the name in the VLDB entry.
Note: Before this commit, administrators could workaround this vos
rename limitation by renaming the volume twice, first to an unused
volume name, then to the actual desired volume name.
Remove the useless checks of the code1 return code after exit in
the RenameVolume() function. These checks for code1 are never performed
since the function exits early when the first VLDB_GetEntryByName()
fails for any reason.
Update the vos rename man page to show vos rename can be used to fix
previously interrupted/failed rename. Also document the -oldname
parameter accepts a numeric volume id to specify the volume to be
renamed.
Change-Id: Ibb5dbe3148e9b8295347925a59cd7bdbccbe8fe0
Reviewed-on: https://gerrit.openafs.org/13720
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2019-07-22 20:20:24 +01:00
|
|
|
The new name may be the same as the current volume name in the VLDB
|
|
|
|
in order to complete a previously interrupted volume rename.
|
|
|
|
|
2013-06-30 03:06:51 +01:00
|
|
|
=include fragments/vos-common.pod
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=head1 OUTPUT
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The B<vos rename> command produces no output if the command succeeds.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
If the volume named by the B<-oldname> argument does not exist, the
|
2005-12-08 12:14:33 +00:00
|
|
|
following message appears:
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
vos: Could not find entry for volume <old volume name>.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=head1 EXAMPLES
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The following example changes the mistaken volume name C<sun4x_56.afsws>
|
|
|
|
to the correct alternative C<sun4x_56.usr.afsws>.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
% vos rename -oldname sun4x_56.afsws -newname sun4x_56.usr.afsws
|
|
|
|
|
|
|
|
=head1 PRIVILEGE REQUIRED
|
|
|
|
|
2005-12-09 14:48:56 +00:00
|
|
|
The issuer must be listed in the F</usr/afs/etc/UserList> file on the
|
|
|
|
machine specified with the B<-server> argument and on each database server
|
|
|
|
machine. If the B<-localauth> flag is included, the issuer must instead be
|
|
|
|
logged on to a server machine as the local superuser C<root>.
|
2005-12-08 12:14:33 +00:00
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
L<vos(1)>
|
|
|
|
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
|
|
|
|
IBM Corporation 2000. <http://www.ibm.com/> All Rights Reserved.
|
|
|
|
|
|
|
|
This documentation is covered by the IBM Public License Version 1.0. It was
|
|
|
|
converted from HTML to POD by software written by Chas Williams and Russ
|
|
|
|
Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.
|