View Issue Details

IDProjectCategoryView StatusLast Update
0000685Subversion for OS/2 & eCSBugpublic2019-05-01 06:10
ReporterLewisRAssigned ToLewisR 
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionreopened 
Summary0000685: svn 1.7.21 (2018-12-30) error when rewinding (updating to previous rev) single file
Descriptionsvn up -r nnnn <filename> should "roll back" or (using the term in the SVN book "unwind") the specified file to the specified revision. Unfortunately, this does not happen with the above build (or with 20190309).
Additional InformationI am returned to a prompt with one of the following:

Under 4OS2:

svn: E720006: Error closing directory: Incorrect internal file identifier.

Under CMD or dash:

Skipped '<filename>'
Summary of conflicts:
  Skipped paths: 1

Under 1.7.16 (2014-08-09), the error is different, but consistent for all shells:

svn: E070008: Error resolving case of '<filename>'

Under 1.6.23 (2013-10-15), the error is also consistent:

Skipped '<filename>'

The same issue occurs when attempting to unwind the file by specific revision or date, and when attempting to move up one or more directory levels and specify the path to the file (even when minding the correct case of the letters in the pathname as well as the file).

It is interesting to note that the following works with the latest (1.7.21) builds:

svn cat -r PREV <filename> ><filename>

It should be noted, though, that:

svn up .

in the directory of the unwound file does not update it to the current revision, though it can successfully be reverted.
TagsNo tags attached.

Activities

Steven Levine

2019-03-13 05:15

manager   ~0003256

FWIW, the regression is probably in the Apache Runtime. The error message implies that one of the Dos APIs failed for some reason. The error number and message correspond to the OS/2 API error ERROR_INVALID_HANDLE and the "Incorrect internal file identifier" message is pulled from the OS0001.MSG.

Steven Levine

2019-03-13 06:47

manager   ~0003257

After I fixed whatever I managed to mess up yesterday, Dave Bashke's OS2TRACE shows the reason for the error pretty clearly. The code is attempting to close a handle that is not open. See svn.trc starting at line 398

The working directory is D:/sla_dev2/TestSVN and the svn command was

  svn up -rPREV testee

testee is a committed file.

svn.trc (18,590 bytes)

Steven Levine

2019-03-14 12:04

manager   ~0003258

The attached should fix this trap. The code is assuming that DosFindFirst will set the value of thedir->handle to 0 if the API fails. The is not true.

dir.c.diff (349 bytes)
diff --git a/file_io/os2/dir.c b/file_io/os2/dir.c
index 3b08355..27d6f05 100644
--- a/file_io/os2/dir.c
+++ b/file_io/os2/dir.c
@@ -114,6 +114,7 @@ APR_DECLARE(apr_status_t) apr_dir_read(apr_finfo_t *finfo, apr_int32_t wanted,
     }
 
     thedir->validentry = FALSE;
+    thedir->handle = 0;
 
     if (rv)
         return APR_FROM_OS_ERROR(rv);
dir.c.diff (349 bytes)

psmedley

2019-03-17 16:55

administrator   ~0003259

http://smedley.id.au/tmp/subversion-1.7.21-os2-20190317.zip has the patch from Steven (not tested)

Steven Levine

2019-03-17 17:28

manager   ~0003260

Thanks Paul. Seems to work fine for both local and repo repos.

LewisR

2019-03-18 06:38

developer   ~0003261

Confirmed fixed. Kudos, guys. I can now update and rewind as expected (tested under 4OS2 as well as CMD and dash). I can specify a single filename, an absolute path, or a relative path. I can rewind a single file and then update that file's directory (and that file) by only specifying the directory name. Nice.

LewisR

2019-03-20 00:56

developer   ~0003262

Last edited: 2019-03-20 00:56

View 2 revisions

Reopening due to some late-discovered side-effects of the proposed patch.

Issue 1 (reported by David A): This version appears to be broken as it seems to now have broken the normal case sensitivity. [N.B.: I have not been able to confirm or deny this locally, mainly due to the next issue.]

Issue 2: svn update at the root of the repository tree seems to cause some difficulties for sqlite:

{0}[d:\] svn up d:\devel\arcaos\trunk
Updating 'D:/devel/arcaos/trunk':
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database

This leaves the workspace in an inconsistent state, requiring cleanup before trying again. Results with other shells similar (the above was from 4OS2).

Steven Levine

2019-03-20 08:04

manager   ~0003263

The original patch was too agressive. It cleared the handle for all errors. It should have cleared the handle only when DosFindFirstFailed.

dir.c.diif2 will avoid this. Be sure to revert the original dir.c.diff patch.

The original patch had the side effect of bypassing all DosFindClose calls, so that we eventually run out of file handles. The sqlite error is simply a red-herring side effect of a file open failing.

We are only going to see this error on large repositories.

dir.c.diff2 (713 bytes)

Steven Levine

2019-03-20 12:38

manager   ~0003264

Reminder sent to: psmedley

Please give the replacement patch a try when yoiu get a moment.

psmedley

2019-03-20 19:14

administrator   ~0003265

Tried building tonight, but had a trap in OS2KRNL and system hangs trying to build after a reboot. Running chkdsk now... might be tomorrow before I have a new executable

psmedley

2019-03-21 18:48

administrator   ~0003266

Updated build at http://smedley.id.au/tmp/subversion-1.7.21-os2-20190321.zip

LewisR

2019-03-22 01:27

developer   ~0003267

Last edited: 2019-03-22 01:28

View 2 revisions

Thanks, Paul.

Unfortunately, with 20190321, I still get:

Updating 'J:/devel/arcaos':
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database

Steven Levine

2019-03-22 09:14

manager   ~0003268

I have to suspect that the first patch (dir.c.diff) was not removed. If this is not it, I will test more here.

psmedley

2019-03-22 09:22

administrator   ~0003269

Pretty sure it was removed, but perhaps the new apr.lib didn't install. I'll confirm this evening.

Steven Levine

2019-03-22 09:45

manager   ~0003270

It looks like the zip ships is shipping with an old svn.map. Please check this when you get a moment. Thanks.

Steven Levine

2019-03-22 11:34

manager   ~0003271

Very odd. It appears that the old patch is still in place. However, for some reason the generated code differs somewhat. Did you rebuild with a different gcc build?

psmedley

2019-03-22 11:38

administrator   ~0003272

Nope, same gcc (8.2.0)

psmedley

2019-03-22 19:00

administrator   ~0003273

http://smedley.id.au/tmp/subversion-1.7.21-os2-20190322.zip

LewisR

2019-03-23 01:26

developer   ~0003274

Sorry, Paul. With 20190322, I still get:

svn: E200031: sqlite: attempt to write a readonly database

when attempting to update the workspace root. The rewind operation works, and I can update that single file to the current rev, but a full update of the workspace fails.

psmedley

2019-03-23 06:15

administrator   ~0003275

fyi, the dir.c I'm using is at http://smedley.id.au/tmp/dir.c

Steven Levine

2019-03-23 08:49

manager   ~0003276

This is:

dir.c:128
    thedir->handle = 0;

leftover from the first patch. It needs to go away.

psmedley

2019-03-23 12:02

administrator   ~0003277

uggh :( I swear I removed that line and checked it was gone ;(

http://smedley.id.au/tmp/subversion-1.7.21-os2-20190323.zip

Steven Levine

2019-03-23 13:15

manager   ~0003278

Thanks. This appears to take care of the sqllite read only issue.

I'm not sure, but I think there may be an unintended delete at:

     finfo->pool = thedir->pool;
     finfo->fname = NULL;
- finfo->valid = 0;

This will leave finfo->valid uninitialized for some code paths.

psmedley

2019-03-23 13:28

administrator   ~0003279

Thanks - yes, that was an accidental delete - it's already fixed in today's build

LewisR

2019-03-24 00:28

developer   ~0003280

I think this one's the charm. If anything else crops up, I'll open fresh or re-open here, as appropriate, but 20190323 resolves the original issue and the unintended side-effect from the original patch.

Thanks!

Issue History

Date Modified Username Field Change
2019-03-12 13:15 LewisR New Issue
2019-03-13 05:15 Steven Levine Note Added: 0003256
2019-03-13 06:47 Steven Levine File Added: svn.trc
2019-03-13 06:47 Steven Levine Note Added: 0003257
2019-03-14 12:04 Steven Levine File Added: dir.c.diff
2019-03-14 12:04 Steven Levine Note Added: 0003258
2019-03-17 16:55 psmedley Note Added: 0003259
2019-03-17 17:28 Steven Levine Note Added: 0003260
2019-03-18 06:38 LewisR Assigned To => LewisR
2019-03-18 06:38 LewisR Status new => resolved
2019-03-18 06:38 LewisR Resolution open => fixed
2019-03-18 06:38 LewisR Note Added: 0003261
2019-03-20 00:56 LewisR Status resolved => feedback
2019-03-20 00:56 LewisR Resolution fixed => reopened
2019-03-20 00:56 LewisR Note Added: 0003262
2019-03-20 00:56 LewisR Note Edited: 0003262 View Revisions
2019-03-20 08:04 Steven Levine File Added: dir.c.diff2
2019-03-20 08:04 Steven Levine Note Added: 0003263
2019-03-20 12:38 Steven Levine Note Added: 0003264
2019-03-20 19:14 psmedley Note Added: 0003265
2019-03-21 18:48 psmedley Note Added: 0003266
2019-03-22 01:27 LewisR Note Added: 0003267
2019-03-22 01:28 LewisR Note Edited: 0003267 View Revisions
2019-03-22 09:14 Steven Levine Note Added: 0003268
2019-03-22 09:22 psmedley Note Added: 0003269
2019-03-22 09:45 Steven Levine Note Added: 0003270
2019-03-22 11:34 Steven Levine Note Added: 0003271
2019-03-22 11:38 psmedley Note Added: 0003272
2019-03-22 19:00 psmedley Note Added: 0003273
2019-03-23 01:26 LewisR Note Added: 0003274
2019-03-23 06:15 psmedley Note Added: 0003275
2019-03-23 08:49 Steven Levine Note Added: 0003276
2019-03-23 12:02 psmedley Note Added: 0003277
2019-03-23 13:15 Steven Levine Note Added: 0003278
2019-03-23 13:28 psmedley Note Added: 0003279
2019-03-24 00:28 LewisR Status feedback => resolved
2019-03-24 00:28 LewisR Note Added: 0003280