PVCS ARCHIVEWORK directory - occasional errors accessing files there

Hi, 

On occasion, we're seeing errors like:

get: can't open file "/home/pvcs/temparc/pv5j8v400001f0fusb.tmp" for reading.
vcs: can't open file "/home/pvcs/temparc/pv5jav400001mgp0s5.tmp" for reading.

The directory above has 777 permissions on RHEL 8.10. The files don't currently exist there and the directory is empty. When files do exist there, I think I recall them being readable by all. That is certainly true of files in the WORKDIR directory.

The ARCHIVEWORK and WORKDIR directories are defined in the master.cfg and subordinate project config files as ARCHIVEWORK.

I've read past support messages here with some indicating that we might want to remove the definitions of ARCHIVEWORK and WORKDIR. But those messages were rather old and I didn't see much in the PVCS docs that really touched on these 'directives' in the config file or whether they should be used (and if not, what the expected outcome would be).

Can you tell me what might cause the above errors? (They occurred one soon after the other in command line code used to checkout and lock source code).Perhaps a collision of temporary filenames in that directory?

Thanks,
Mark

  • Verified Answer

    +1  

    Hello Mark,

    ARCHIVEWORK is used for .tmp files needed to create/update an archive file.
    WORKDIR is used for .tmp files needed to update a workfile (e.g apply reverse deltas, expand keywords, etc.).

    This could potentially be a variant of the group / umask issue from your previous post. Because setuid mode is enabled on this installation, the effective user is switched between the end-user and the "pvcs" user and both need to be able to read the files. If abandoned files are indeed readable by user+group+other, this would be an unexpected error. Please run with umask 022 (or less strict) and ensure end-users are members of the group shown by "vmsetsuid -verify".

    I'm typically not a fan of ARCHIVEWORK and WORKDIR because these directives override the good default directories that are otherwise defined by non-CLI PVCS VM applications. However, your CLI case is the one scenario where having these directives may still make sense, as the CLI default is to create those files in the current directory.

    For now, please check your umask and group ownership. If those are correct, and the issue is reproducible, I recommend opening a support case for in-depth troubleshooting. If you have not done this yet, I recommend upgrading to PVCS VM 8.7.0.x in the near future, as use of older releases require Extended Support after April 30th 2025.

    With kind regards,

    - Richard.

  • Verified Answer

    +1 in reply to   

    Thank you Richard!

    Yes, our programmers have been battling a STIG (V-230384) that requires the default system umask.to be 077. (Aren't STIGs fun ... and so sensible Slight smile). It's funny that the STIG 'check' is less than robust: sudo grep -ir ^umask /home | grep -v '.bash_history' 

    You, of course, nailed this cause as you've done for so many other issues in the past. 

    Thanks so much and I really appreciate the added details.

    Mark

  • Verified Answer

    +1   in reply to 

    Hello Mark,

    You are very welcome. That STIG umask check is... interesting.

    If the setuid umask issue is proving bothersome, you could consider switching to the PVCS VM File Server. In this setup, update operations are no longer performed by the commands executed by the end-user but are being passed to the File Server process, which performs the operations as the "pvcs" user it runs as. In this setup setuid mode can be disabled, taking away the umask requirements.

    File Server operations require fully qualified paths, so using relative paths could theoretically be problematic. However, CLI commands often compute absolute paths before performing operations, including when using path-less workfile names where the corresponding archives are located using the VCSCFG directive in the CFG file. Depending on your users' actions, it may not be a real-world problem.

    Worth trying out perhaps, as you could easily switch back and forth.

    With kind regards,

    - Richard.