Why adding metadata.xml files to source control in ClearCase fail?

I am a member of a team responsible for developing an Eclipse based application at Scania.

We have used IBM Rational ClearCase for more than 3 years but recently we开发者_JS百科 have encountered the following problem when creating or copying a directory in eclipse navigator.

The directory that will be created or copied contains other directories and a metadata.xml for every sub-directory.

The metadata.xml contains information about the directory.

Our eclipse uses SCM-Adapter for ClearCase which is installed by its plug-in.

When creating or copying the directory ClearCase asks for if the directory will be added to source control or not.

When we press OK-button we get the following problem message.

After verifying the message CleraCase adds the directory, all its sub-directories and files and checks in them except all metadata.xml files that are created with version 0 and are hijacked.

The message:

Error adding 'C:\views\<myview>\<myDirectory>\metadata.xml' to source control.
Unable to rename "C:\views\<myview>\<myDirectory>\metadata.xml" to "C:\views\<myview>\<myDirectory>\metadata.xml.keep": Permission denied. 
Errors were encountered in loading "<myDirectory>\metadata.xml". Trouble updating name "metadata.xml" in snapshot view: error detected by ClearCase subsystem.
A separate update may need to be performed in order to reflect the results of the operation in the snapshot view. 
Operation "fileutl_rename_unique" failed: Permission denied.

The problem started for 2 or 3 mounts ago, which we did not have before, and is the same for both Windows XP and 7. We are using ClearCase version 7.1.1.4, Eclipse 3.6.1 (32 bits) and the view is a Snapshot view.

I have tried to find the reason but I have not succeeded. Every help or comment will be appreciated highly.

---

This is usually due to some ACL issue, or to some process blocking the resources (here metadata.xml) being processed.

See also the IBM technote "swg21148768: Unable to rename "<file>" to "<file>.keep": Permission denied"

Cause 1:

In this case, the file that was hijacked was part of an application that had a process running in the background causing the file to be locked thus not allowing ClearCase to rename it with the .keep extension.

Cause 2:

There is another element in that directory with the same name, but has a different case.
For example, the directory contains both elements: FOO.C and foo.c.

Cause 3:

This issue can also occur when using clearfsimport to perform multiple imports of the same data set.

Cause 4:

If you have two or more views with the same name but not the same case and the MVFS is configured as in Cause 2 (Case Insensitive MVFS and Case Preserving). Example:

view1
View1
vIEw1