When I create a symbolic link in Windows 7 using the mklink-command and then query that path name via Python's os.path.islink()-function, the function correctly returns True. Also, when calling the dir-command in the directory containing my link, its type is correctly displayed as <SYMLINK>.
With a symbolic ClearCase link (created via cleartool ln -s ...), however, os.path.islink() always returns False, and Window's dir-command displays the element as a normal file (i.e. without the <SYMLINK> attribute).
This is a problem because I'm writing a script that recursively descends into a directory tree (which may or may not be under ClearCase-control), and in order to be able to avoid infinite recursion I need to be able to detect whether a directory is an actual directory or just a symlink to another directory. Similarily, I need to be able to deal with symlinks to files as well to avoid processing the same file more than once.
Has anyone else encountered this issue? Using ClearCase v7.1.2.7, by the way.
As mentioned in this technote, ClearCase links are different from Windows mklink:
C:\>mklink /D link_name Y:\<vobtag>\dir3
symbolic link created for link_name <<===>> Y:\<vobtag>\dir3
>cd link_name
>cleartool ls
(system crash)
The feature "reparse points" created the links that mklink generated. Reparse points are implemented on NTFS, but not on the MVFS itself.
When you use a snapshot view, usually NTFS file sytems stores the files. This is why mklink works error free in that situation.
When you use dynamic views, the requests go to MVFS as a target file system, although NTFS stores the view and vob. MVFS does not support reparse points and fails with an invalid parameter at creation time or a BSOD and reboot the system.
So, with snapshot or dynamic view, it would be better for your python script to do a cleartool ls, and parse the result to detect ClearCase symlinks.