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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
