Locked file - Windows - filesystem number instead of path is shown in error message

[Martin Rupp]

Hi,

If a file is locked I get an error message like:

Lock failed: C:\test\svn\TestSvn\Test-o1.fodt
Error: Path '/Martin/Test-o1.fodt' is already locked by user 'martin' in
filesystem
Error: '75510a91-dada-4f23-b575-03fe34008164'

(TortoiseSVN 1.14.0, Build 28885 - 64 Bit , 2020/05/24 13:32:45)

It is okay that I get an error but I need the path of the working copy
instead of a hex number which doesn't help me.
Why I get a such unknown number instead a path?

c:\test\svn\TestSvn>svn lock Test-o1.fodt
svn: warning: W160035: Path '/Martin/Test-o1.fodt' is already locked by
user 'martin' in filesystem '75510a91-dada-4f23-b575-03fe34008164'
svn: E200009: One or more locks could not be obtained

c:\test\svn\TestSvn>svn lock Test-o1.fodt
svn: warning: W160035: Path '/Martin/Test-o1.fodt' is already locked by
user 'martin' in filesystem '75510a91-dada-4f23-b575-03fe34008164'
svn: E200009: One or more locks could not be obtained

c:\test\svn\TestSvn>svn --version
svn, version 1.14.0 (r1876290)
   compiled May 24 2020, 17:07:49 on x86-microsoft-windows

Copyright (C) 2020 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using
serf.
  - using serf 1.3.9 (compiled with 1.3.9)
  - handles 'http' scheme
  - handles 'https' scheme

The following authentication credential caches are available:

* Wincrypt cache in E:\Users\Martin-User\AppData\Roaming\Subversion

I have also tried it with cygwin:

Martin-User@JODA /cygdrive/c/Test/svn/TestSvn
$ svn lock Test-o1.fodt
svn: Warnung: W160035: Path '/Martin/Test-o1.fodt' is already locked by
user 'martin' in filesystem '75510a91-dada-4f23-b575-03fe34008164'
svn: E200009: One or more locks could not be obtained

What is the "filesystem '75510a91-dada-4f23-b575-03fe34008164'"?

It seems it is the id for the svnserver (svnserve).

If I use svn auth the same id is used for the login area:

Martin-User@JODA /cygdrive/c/Test/svn/TestSvn
$ svn auth
------------------------------------------------------------------------
Art der Zugangsdaten: svn.simple
Anmeldebereich: <svn://qnap-nas-ts-231p3:3690>
75510a91-dada-4f23-b575-03fe34008164
Passwortspeicher: wincrypt
Passwort: [nicht angezeigt]
Benutzername: martin

Credentials cache in '/home/Martin-User/.subversion' contains 1 credential

But how can I see in which path (working copy) on which computer the
file is locked?

With best regards

Martin

[Daniel Sahlberg]

There is already a somewhat similar request in JIRA (https://issues.apache.org/jira/browse/SVN-4857). It doesn't seem like any work has done there. The idea would be to put the computer name in the lock message. But as mentioned in the issue, it would be difficult for the server to work out the computer name and even more difficult to work out the working copy path.

You can of course manually add this information in the lock message and then inspect it using svn info [url to file in the repository] (or in TortoiseSVN: "Check for modifications", "Check repository")

There is a client side Hook Scripts feature in TortoiseSVN. The Pre-Lock script locks promising from the documentation (it should be executed before the lock dialog is shown and the script should be able to figure out both the computer and the path and put it in the log message). However I can't make it work from a quick test and I don't have time to dig deeper right now. If you try it out and it doesn't work, please reach out to the TortoiseSVN mailing lists (https://tortoisesvn.net/community.html).

Kind regards,

Daniel Sahlberg

[Martin Rupp]

Dear Mr. Sahlberg,

thank you for your answer.

I have played with the client hook pre-lock script of Tortoise SVN. The idea is very good.
The first argument is a temporary file. It should contain the paths to the files which should be locked.
But unfortunately this file is empty.
Therefore I am not able to add the paths to the log message via client hook scripts.

The svn lock command should know which file(s) in which working copy is (are) locked.

I don't understand why this command doesn't transfer this information to the server and doesn't show it in the log or better in the message which is shown if another user wants to get a lock on this file.

I need much time to find the working copy (plus client computer name) where a file is locked because I don't know where it is locked.

A software which provides the locking feature should also told the user where it is locked.
I know this from other software products.

I don't want to do a force unlock.

As workaround I use subversion usernames which contains the hostnames of the clients.

So I know on which host the lock was done. 

But I need also the path of the working copy and I don't want to add also each working copy to the username

Best regards

Martin Rupp

[Daniel Sahlberg]

Den sön 3 jan. 2021 kl 16:43 skrev Martin Rupp <marti...@nefkom.net>:

Dear Mr. Sahlberg,

thank you for your answer.

I have played with the client hook pre-lock script of Tortoise SVN. The idea is very good.
The first argument is a temporary file. It should contain the paths to the files which should be locked.
But unfortunately this file is empty.
Therefore I am not able to add the paths to the log message via client hook scripts.

I saw this as well. This is surely a bug in TortoiseSVN which should be reported in their mailing list (https://tortoisesvn.net/community.html).

The svn lock command should know which file(s) in which working copy is (are) locked.

I don't understand why this command doesn't transfer this information to the server and doesn't show it in the log or better in the message which is shown if another user wants to get a lock on this file.

Probably it wasn't deemed necessary for the server to know this information when the network protocols were designed. (As you can see in JIRA one of the developers expressed privacy concerns regarding transmitting too much information from the client to the server). Any client is free to add this information in the lock message and to get and display the lock message whenever it gets the warning message W160035.

I need much time to find the working copy (plus client computer name) where a file is locked because I don't know where it is locked.

I can agree with you, in fact I even have the same problem myself. So far I have solved it by being strict on only using one specific WC when I edit the files that require locking (ie, binary files).

A software which provides the locking feature should also told the user where it is locked.
I know this from other software products.

Subversion is an open source software and patches are always welcome (in d...@subversion.apache.org).

Kind regards,

Daniel Sahlberg

[Daniel Sahlberg]

For reference, the discussion over at Tortoisesvn-dev: https://groups.google.com/g/tortoisesvn-dev/c/A9g8NgQic2Q

TLDR; TortoiseSVN's pre-lock client-side hookscript can be used to accomplish this however for optimum use (including displaying the lock message) there are a few bugfixes in the next release.

Den sön 3 jan. 2021 kl 16:43 skrev Martin Rupp <marti...@nefkom.net>:

[Daniel Shahaf]

Martin Rupp wrote on Sun, 03 Jan 2021 03:27 +00:00:
> What is the "filesystem '75510a91-dada-4f23-b575-03fe34008164'"?
>
> It seems it is the id for the svnserver (svnserve).
>

It's the repository UUID. The error message gives the repository UUID
because there's no reason for the client to know the repository's disk
path on the server.

It appears in `svn auth` output because svnserve uses the UUID as the
realm string when no realm is specified in svnserve.conf.

Changing the realm string would invalidate client's cached credentials
to that repository URL, since the cache is keyed on the "<$URL> $REALM"
string, as shown by `svn auth`.

> But how can I see in which path (working copy) on which computer the
> file is locked?

As mentioned, have clients supply this information in the lock message.
You can enforce that with a pre-lock hook.