Problem:

Performed a rebuild on a Vision file using vutil -r.  When prompted to replace the file and answering yes an error that access to the file was denied was displayed.

Resolution:

Rebuilding files should only be done when there will be no other access to the file.

The situation described occurred due to the timing of vutil locking and unlocking the files. Vutil -rebuild closes the input file (the original) before the output file (rebuilt file).

The default mode for vutil -rebuild is bulk-addition. Vision 4 and Vision 5 files have separate data and index files, so it is possible when the lock on the input file is released the output file's index is still being updated by the bulk-addition mode. For a large file there could be a lengthy delay before the output file is closed and ready to copy.  It is during this delay another process likely opened the original file causing vutil to be denied access for the copy.  

(Note that Vision 3 files have no separate index and do not experience a delay.)

Using vutil's --slow option avoids the use of bulk-addition and eliminates such a delay. The option is really misnamed; it isn't necessarily slower, it only means don't use bulk-addition. Sometimes even slightly faster rebuild times are seen when using --slow.

The file is also unlocked when waiting for the response to "Replace original file with new one?" Use the -a rebuild option to automatically replace the file.  However, if records were lost in the rebuild it will notify you and then ask the question anyway. Use -aa to automatically replace the file, even if records were lost.

In summary, using "vutil -r --slow -aa filename" should prevent other processes from accessing the file until the rebuild is complete.

Version 8.0 includes a modification to vutil that changes the order in which the files are closed (output first then input), so the --slow option can be omitted if desired.