2

I am running an asp.net application (VS2008/.net 3.5) and when running it under VS in debug more it works fine.

It reads files and directories from a network share happily.

I can run "cleartool startview [dynamic view name]" ok, I can "cleartool mount [vob]" happily.

But if I try to test for the existance of a file within the vob it can't see it.

So I tried something different, I now run "cleartool ls -short -vob_only [filename]" to test for existance.

For both of those it works fine running under VS2008 but won't work when running under IIS post deployment.

I have the set and the user has valid access to ClearCase.

Any ideas?

Alan Mullett
  • 1,106
  • 13
  • 26

2 Answers2

0

If you use the built-in webserver (Cassini) during development the webserver is running as you and have access to your networked drives etc. IIS on the other hand uses a different user account and doesn't share your user profile including your ClearCase views etc. That may explain your problems.

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
  • That's what I first thought - but I do have access to network drives that can only be accesed through a domain account protected using the same groups as the ClearCase VOB. So it appears that ClearCase has additional requirements over and above those of the windows share. – Alan Mullett Aug 04 '09 at 12:39
  • If I understand you correctly you have an ASP.NET application that accesses dynamic ClearCase views that are mapped to network drive letters. As IIS is running as a different user it doesn't see these network driver letters. The IIS user account may have access to the VOB's but the mappings that you see when you are logged are not visible to IIS. – Martin Liversage Aug 04 '09 at 13:19
0

I found the problem and a resolution to this. The problem is that ClearCase is using the process user for authentication whereas the shared drive access mentioned in the original question is using the thread user.

The reason for this is the when accessing ClearCase it spawns off a new process - and child processes always use the parents process security context and not the current thread's.

The way around this was to run the web application within its own application pool which is running as a user with rights to access ClearCase. An inflation of rights beyond what should be really necessary however it did the trick.

Alan Mullett
  • 1,106
  • 13
  • 26