This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PVCS - Could not access file because it is in use by another user.

Hi 

I have two instances of users being unable to check out documents with the error:

'Could not access file because it is in use by another user. Check out <file>. <archive>'

the users privilages are correct, I can check them out as SuperUser, others with the same privs can check them out as well.

Everything on the fileserver looks ok.....no sem leftovers that I can see....

Can anyone offer some advice please?

Many thanks

Parents
  • Suggested Answer

    0  

    Hello Chris,

    File In Use errors can be caused by an inability to obtain a semaphore, or an inability to to write the target file. As a test, please split the Check-out into a separate Get and Lock operation.

    • If the Lock operation works but the Get operation fails, the problem is with the file the user is trying to write to (permissions, open in an editor, etc.).
    • If the Get operation works but the Lock operation fails,  there either is a problem with an existing semaphore, or VM is unable to create one. Should it prove hard to find the origin of this, seeing the output from VM_Debug.bat (from KB doc S141099) might prove helpful. You might want to open a support case for this and upload that file to it.

    With kind regards,

    - Richard.

  • 0 in reply to   

    Hi Richard and thanks for the speedy response.

    One of the users with the issue cannot do a get, lock or check out (we have literally just tried it), but I can still do all three.

    I removed his access to the project then re-instated it...no change.

    Anymore options?

    Thanks

    Chris

  • 0   in reply to 

    Hi Chris,

    That is peculiar. Please ask the user to re-run the Get operation and change the target location to another path that has enough space and has no pre-existing copy of the file, like their local temp folder.

    Which VM client is the user running (Desktop Client, Web Client, other?)

    Kind regards,

    - Richard.

  • 0 in reply to   

    Hi Richard

    One of my guys has just tested the idea (get / checked out to c:\temp) and that has worked, but still cannot get / check out to their default location (they can with other files).

    Its so very weird...

    Its the desktop client by the way....

    Thanks for the assistance so far....really appreciated...

    Chris

  • Suggested Answer

    0   in reply to 

    Hi Chris,

    For a single file, have the user try this:

    1. Copy the "Copy To:" field of the Get or Check-out operation without the file part (i.e. target directory).
    2. Launch File Explorer and paste this path as-is.
    3. If the target file exists, use right-click | Properties to confirm they can both unset and set the Read-only attribute.
    4. If the target file exists, confirm they can rename the file.
    5. If the target file exists, confirm they can delete the renamed file.
    6. Confirm they can create the target file (e.g., using Notepad).

    If any of steps 3-6 fail, Version Manager will fail to perform a Get / Check-out for that file as well.

    Kind regards,

    - Richard.

Reply
  • Suggested Answer

    0   in reply to 

    Hi Chris,

    For a single file, have the user try this:

    1. Copy the "Copy To:" field of the Get or Check-out operation without the file part (i.e. target directory).
    2. Launch File Explorer and paste this path as-is.
    3. If the target file exists, use right-click | Properties to confirm they can both unset and set the Read-only attribute.
    4. If the target file exists, confirm they can rename the file.
    5. If the target file exists, confirm they can delete the renamed file.
    6. Confirm they can create the target file (e.g., using Notepad).

    If any of steps 3-6 fail, Version Manager will fail to perform a Get / Check-out for that file as well.

    Kind regards,

    - Richard.

Children
  • 0   in reply to   

    Important caveat: if steps 3/4/5 require the confirmation of an Elevated Access prompt to complete the operation, Version Manager will fail as well: the user has to be able to perform these operations with their default privileges.

    Kind regards,

    - Richard.