View Issue Details

IDProjectCategoryView StatusLast Update
0000678Subversion for OS/2 & eCSBugpublic2018-08-27 07:27
ReporterThomasikusAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformIBM Thinkpad T43pOSecomStationOS Version2.1
Summary0000678: 'svn update' command fails with "File exists" message
DescriptionSubversion client 1.7.21, updated 2015-08-10.
Trying to update the working copy from the repository resulted in a 'file exists' error. The Subversion client seemed unable to remove files from a temporary directory. It is possible that the error is caused by an interaction with the encrypted virtual file system (see below).
Steps To Reproduce'svn checkout' command worked properly, creating a local copy of the particular project I am working with. This was the first time I used Subversion. When I later tried to update the working copy (I had not made any changes myself, only wanted to update my copy with other peoples' changes), the following occurred:
[k:\prevas\asl1253p\octave]svn update ControlEngine
Updating 'ControlEngine':
U ControlEngine/trunk/UserInterface/show_progress.m
svn: E720080: Can't move 'K:/Prevas/ASL1253P/octave/ControlEngine/.svn/tmp/svn-NZF53f' to 'K:/Prevas/ASL1253P/octave/Con
trolEngine/trunk/UserInterface/show_progress.m': The file exists.

Running the 'svn update' command again:
[k:\prevas\asl1253p\octave]svn update ControlEngine
svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted

I tried to fix the problem using the 'svn cleanup' command:
[k:\prevas\asl1253p\octave]svn cleanup ControlEngine
svn: E720080: Can't move 'K:/Prevas/ASL1253P/octave/ControlEngine/.svn/tmp/svn-Fe6mwk' to 'K:/Prevas/ASL1253P/octave/Con
trolEngine/trunk/UserInterface/show_progress.m': The file exists.

It appears that the svn client downloaded the modified files to a temporary directory but then couldn't move them to the actual working copy files. I had to delete the (old) files manually. I don't remember now if the 'svn cleanup' command then worked properly or if I had to manually remove the files from the temporary directory as well. When all files were updated, the 'svn update' command confirmed that my working copy was up to date.
Additional InformationIt is possible that the malfunction is caused by an interaction with the file system. I am using an encrypted virtual file system for the K: drive (since the files are company confidential information). The virtual file system is the AEFS file system with AES encryption, found at https://nixos.org/~eelco/aefs/. I use version 0.2.1 with the updated aefsdmn-r286.zip mentioned on the page. The AEFS file system seems to work fine, I can create files, edit, move, delete etc.
I haven't tried using the Subversion client with a directory on the JFS drive (I can test that but I can't access the company server until my return from vacation on August 6, 2018). I marked the severity as 'minor' since it is possible that the svn client works on JFS and probably few people use the AEFS file system. For me, it's of course a bigger problem :-)
TagsNo tags attached.

Activities

Thomasikus

2018-08-24 06:52

reporter   ~0003197

I have now verified that the bug only happens when working directly from the virtual AEFS file system. I copied the whole client directory to a JFS partition, then updating worked perfectly. A theory could be that the AEFS file system lacks some API call that is used by Subversion, perhaps some sort of file update operation.
/Thomas

psmedley

2018-08-25 08:36

administrator   ~0003198

Interesting... it's also possible that APR or klibc uses the file system type to determine some capability and that AEFS is unknown so misses something... will try investigate...

psmedley

2018-08-26 18:48

administrator   ~0003199

libc will definitely treat AEFS as if it's a file system that doesn't support Extended Attributes - this could definitely lead to issues....

Thomasikus

2018-08-27 07:02

reporter   ~0003200

I take it then that libc doesn't actually query the file system as to its capabilities/properties. Is there even such an API call? Assuming that is the problem, is there some way to tell libc that AEFS handles extended attributes? It seems to do so as far as I can tell.

psmedley

2018-08-27 07:27

administrator   ~0003201

According to the AEFS docs, it supports EA's. http://trac.netlabs.org/libc/ticket/21 is the relevant ticket

I'll try adding in AEFS and build a new libc066.dll

Issue History

Date Modified Username Field Change
2018-07-27 09:23 Thomasikus New Issue
2018-08-24 06:52 Thomasikus Note Added: 0003197
2018-08-25 08:36 psmedley Note Added: 0003198
2018-08-26 18:48 psmedley Note Added: 0003199
2018-08-27 07:02 Thomasikus Note Added: 0003200
2018-08-27 07:27 psmedley Note Added: 0003201