Access labels of file through extended filename as directory

Question

I want to list all labels of a specific file in ClearCase. Based on the last approach in the accepted answer at (how to find all the labels for a given file in clearcase) I

Answer 1

I don't get it. Why doesn't dir show these files?

Because dir is a Windows command which will list Windows filesystem files, not MVFS (Multi-Version FileSystem) ones, used by a dynamic view.

I don't know what is different with those files. Maybe the file extension/type?

Everything after the @@ is a version-extended pathname (see man page), emulated as a Windows file by the MVFS dynamic view.

But should this matter?

If you are using Windows commands (and not cleartool queries), it should not, as those extended paths are supposed to be directly visible by Windows.
They are accessible (copy filename@@\labelname targetfile), but should be also visible (listed by a Windows filesystem-based dir command)

In particular, for Version labels in extended namespace:

Version labels appear in the extended namespace as hard links (UNIX and Linux) or as additional files (Windows).

On Windows, if version \main\4 of an element is labeled RLS_1, the extended namespace directory corresponding to the element's main branch lists both 4 and RLS_1:

Z:\myvob\src> dir sort.c@@\main
2006-11-10T17:34                1846 4
 ...
2006-11-10T17:34                1846 RLS_1

If the label type was created with the once-per-element restriction, on Windows, an entry for the labeled version appears in the element's top-level directory:

Z:\myvob\src> dir sort.c@@ 2006-11-10T17:34                1846 RLS_1

---

Don't forget also that a pathnames can involve multiple elements:

After a path name crosses over into the extended namespace with @@, you must specify a version for each succeeding element in the path name.
For example:

To automatically select versions for elements proj and src: cross over to extended namespace at directory element include, specifying a version of include and a version of sort.h:

Windows:

\proj_vob\src@@\RLS_1\include\RLS_1\sort.h\RLS_1

---

The OP adds in the comment:

The problem was the once-per-element restriction. This is the default setting in our environment but someone used the once-per-branch setting in his VOB. So the label files could not be created at the top-level directory.

The once-per-element restriction is the mklbtype default.
A mklbtype -pbranch command creates a label type that can be used once on each branch of an element.