[OpenAFS] afs-1.5.10 on XP -- file locking and MSI properties

[Tim Czerwonka]

For OpenAFS-1.5.10 on WinXP...

I'm wondering if anyone has noticed this weird behavior with regard
to checking the ProductVersion strings in an arbitrary MSI using the 
1.5.10 AFS client while not authenticated...or if it's just us...it
could be just us...

Up front: the 1.5.10 client installs OK and initial testing shows that 
it's pretty fast (~2x) on read compared to the 1.4.2 client.  The file 
locking behavior appears to work as advertised in the release notes.  

Some background: we keep all of our MSIs in AFS and an unauthenticated
process on each workstation runs daily, checking the installed MSI
ProductVersion against the ProductVersion of the MSI in AFS -- making
additions/updates to the local install as necessary.  We use msidb.exe 
(from the Platform SDK for Win Installer developers) to extract the 
ProductVersion from the MSI.  

The problem:  This works fine on 1.4.2 (and previous).  With 1.5.10, 
msidb.exe fails to produce any info because msidb can't get a write 
(?!?!) lock on the MSI.  

ACL that doesn't work with a non-replicated volume:
system:anyuser rlk

ACL that *does* work with a non-replicated volume:
system:anyuser rlkw
(yuck)

ACL that works with a replicated volume:
system:anyuser rl




I offer the following vbs script that does the same thing without all 
the other msidb features: /afs/cs.wisc.edu/u/t/i/timc/public/prodversion.vbs

It fails in the same manner -- The OpenDatabase call is made read-only
yet it requires "system:anyuser rlkw" ACLs to work.

So, I'll admit, AFS appears to work as advertised here...

But, I'm wondering if anyone else keeps their MSIs out in AFS and relies
upon fetching any MSI property for anything?  Seems like a reasonable thing
to do in any sort of Windows configuration managment scheme.

If you do, have you tried this out using afs-1.5.latest?  We can get
around this easy enough for our own MSIs, but wouldn't be surprised
if some other random MSI (Adobe, Microsoft, etc) tried to do something
similar and failed on install due to inability to grab (of all things) 
a write lock.



Thanks--
--Tim