View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000678 | Subversion for OS/2 & eCS | Bug | public | 2018-07-26 23:53 | 2022-05-24 18:39 |
| Reporter | Thomasikus | Assigned To | psmedley | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Platform | IBM Thinkpad T43p | OS | ecomStation | OS Version | 2.1 |
| Summary | 0000678: 'svn update' command fails with "File exists" message | ||||
| Description | Subversion 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 Information | It 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 :-) | ||||
| Tags | No tags attached. | ||||
|
|
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 |
|
|
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... |
|
|
libc will definitely treat AEFS as if it's a file system that doesn't support Extended Attributes - this could definitely lead to issues.... |
|
|
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. |
|
|
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 |
|
|
THis is a klibc issue and needs to be raised there. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-07-26 23:53 | Thomasikus | New Issue | |
| 2018-08-23 21:22 | Thomasikus | Note Added: 0003197 | |
| 2018-08-24 23:06 | psmedley | Note Added: 0003198 | |
| 2018-08-26 09:18 | psmedley | Note Added: 0003199 | |
| 2018-08-26 21:32 | Thomasikus | Note Added: 0003200 | |
| 2018-08-26 21:57 | psmedley | Note Added: 0003201 | |
| 2020-08-24 03:15 | psmedley | Assigned To | => psmedley |
| 2020-08-24 03:15 | psmedley | Status | new => closed |
| 2020-08-24 03:15 | psmedley | Resolution | open => won't fix |
| 2020-08-24 03:15 | psmedley | Note Added: 0003512 |
