I have found the solution to this problem.
I had to include an '@ echo off' in the bat file that called my perl
script. Without it the "UUID Token:" would be set to the full call of
the script. Here is an example of how it is working properly:
C:\Documents and Settings\Administrator>svnadmin lslocks
E:\svn\PES_Documents | more
Path: /CSIQA/Status/Longbow 2/ATF OPENs.xls
UUID Token: opaquelocktoken:f6efca00-0a6e-ee47-8335-29bacd3dabf3
Owner: beaulc
Created: 2009-10-22 11:31:01 -0400 (Thu, 22 Oct 2009)
Expires:
Comment (1 line):
Here is it if I steal the lock but first take with the "@ echo off"
commented out:
C:\Documents and Settings\Administrator>svnadmin lslocks
E:\svn\PES_Documents | more
Path: /CSIQA/Status/Longbow 2/ATF OPENs.xls
UUID Token:
C:\Program Files\Apache Software
Foundation\Apache2.2>C:\perl\bin\perl.exe
E:\SVN\PES_DOCUMENTS\hooks\pre-lock.pl E:\SVN
\PES_DOCUMENTS "/CSIQA/Status/Longbow 2/ATF OPENs.xls" morgag
Owner: morgag
Created: 2009-10-22 12:30:38 -0400 (Thu, 22 Oct 2009)
Expires:
Comment (1 line):
I am glad I found the solution, but is this expected results?
-garrett
> _____________________________________________
> From: Morgan, Garrett
> Sent: Wednesday, October 21, 2009 5:06 PM
> To: 'users_at_subversion.tigris.org'
> Subject: Unlocking stolen file results in 400 Bad Request with
> token-header error
>
> Hello All.
>
> Hopefully someone can help me with a rather strange issue I am having.
> I have tried to no end to research this. I will start off by saying I
> am not a SubVersion or apache expert and am coming up to speed to help
> maintain/admin a SubVersion environment.
>
> Our environment consists of SVN 1.6.5 with apache 2.2.13. My groups
> specific folder is mostly excel and doc sheets, and we decided to go
> with the lock-modify-unlock procedure. A user can lock-modify-unlock
> a file fine, but once an admin steals the lock from a user (admins
> permitted only through pre-lock perl script), no user can unlock ANY
> file. A user can lock and steal locks (if allowed) however.
>
> The issue cleared itself once, I assume because of a timeout, I did
> nothing to clear the issue.
>
> There are other folders in the repository without the needs-lock
> property which do not exhibit these properties.
>
> When the user tries to unlock any file they get a 400 bad request
> error to the "unlock" command. The apache logs show the following:
>
> [Wed Oct 21 15:59:21 2009] [error] [client 128.221.37.140] The
> locktoken specified in the "Lock-Token:" header did not specify one of
> this resource's locktoken(s). [400, #0]
>
> So it appears to me the locktoken is not getting updated properly to
> the new lock owner (if I am understanding it correctly). The odd
> thing as well, is I have a test SubVersion environment that I used to
> write the pre-lock script and was using to get myself and team
> familiar with SubV and Apache before jumping onboard with the existing
> environment. My test environment does NOT use Active Directory
> authentication through apache, and it does not exhibit this problem,
> whereas the live environment uses it. I did not set that portion up
> at all though so if we wanted to explore that I'd have to ask the
> person who did, who is also baffled by this problem.
>
>
> Thanks in advance for any help/guidance.
>
> Garrett Morgan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2410302
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-22 18:37:05 CEST