understand about dot files in the view storage

View storage dot files:

.cow files

• Q: There are files in the view storage directory that are named "*.cow". What are these?
  
  A: The .cow (copy-on-write) files are a result of winked in derived objects (DO's). When the DOs are winked in, their permission modes are read-only. When you do a subsequent build and need to overwrite/update the DO, a .cow file is created with write permissions so the overwrite can happen.
  
  Example:
  -rw-rw-rw- 1 joe devgrp1 369780 Nov 14 15:42 3522d2f4.015b.cow
  -rw-rw-rw- 1 joe devgrp1 318604 Nov 14 15:39 3b82d525.00ca.cow
  -rw-rw-rw- 1 joe devgrp1 113568 Nov 14 16:41 3f46d7fd.07b2.cow
• Q: What is the correct way to remove the .cow files?
  
  A: Remove (rm or del) the winked in file in the view, from the VOB mount point.
  
  Note: Do not remove (rm or del) the .cow files.
• Q: What happens if someone removes the .cow files? Does it break the view or cause problems with the view database?
  
  A: Somewhat. Random errors will be encountered when trying to access this file from the VOB mount point where it was winked in.
• Q: These files appear to be taking up a lot of space in the view storage area, are they really necessary? Why does the view hang onto them?
  
  A: Yes, these files are necessary; they are being used in the view. There is a name somewhere in a VOB mount point that refers to these files. Any file that is not legitimately referenced will get moved to the view's lost+found directory when a recoverview is done.

.mvfsxxxxxx files

• Q: There are also files named .mvfsxxxxxxx in my view. They show up as view private files when I run cleartool lsprivate in my dynamic view. How did they get there and can I delete them?
  
  A: These are files that were removed when another process still had them open. In order to allow the open process to continue reading the file after the file has been removed (UNIX semantics) the original file is renamed to some temporary unique name (just as in NFS).
  
  The .MVFS files can be deleted using standard operating system remove commands (rm or del).
  
  Example: cleartool lsprivate | fgrep '.mvfs' | rm"
• Q: Will recoverview clean up .mvfs* files?
  
  A: Recoverview will not remove these files.

.cmake.state files

• Q: What are .cmake.state files? Is there a performance impact if they are removed?
  
  A: There is a performance impact if these files are removed. They contain cached config records for the objects in that directory. If they are removed, the next build in that directory will have to go to the VOB and refetch all the config records again. That can be very slow.
  
  Review the ClearCase Administrators Guide on the topic of Improving Client Host Performance
  for additional performance information.

Q: Is there a way users can manage the view storage area besides removing the view? Is recoverview the only option for cleaning these temporary files?

A: The cleartool lsprivate command shows file usage in a view, for all VOBs involved.
cleartool space can be used to report a views disk space usage.

Review appropriate sections of the Rational ClearCase and Rational ClearCase LT Command Reference for usage and syntax of cleartool recoverview, cleartool lsprivate and cleartool space.

13. How do I – understand about the view_db.state file

The view_db.state file is located in the top level of the view storage directory, and it indicates to the view_server what state the view is in upon restart of the view server process.

This state file allows the view_server to resume the operation of a given state if the operation is interrupted.

The states are:

i - idle
m - modified
d - dumped
r - recovery needed
n - new

In general, this file should not be modified as the view_server process writes to it.

Under normal circumstances, the view_db.state file will contain only the letter "i" (plus a carriage return).