Old (readonly) SVNKit Issues Tracker, new one is at http://issues.tmatesoft.com/
ATTENTION: You are browsing old (readonly) SVNKit Issues Tracker!
Please find new one at http://issues.tmatesoft.com/
If you have an account here, it should work in the new tracker as well.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000360SVNKitbugpublic2010-02-17 11:082010-02-17 16:54
Reporternubela 
Assigned Tooka 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versiontrunk 
Target VersionFixed in Version 
Summary0000360: bug rename() in SvnFileUtil that will always lead to an Exception being thrown in non-Windows setup
DescriptionIn line 494 of SvnFileUtil.java

boolean renamed = false;
        if (!isWindows) {
            renamed = src.renameTo(dst);
        } else {

You can see that in non-windows setup, it does the renaming deed and doesn't change renamed = true.

Hence svnkit will always fail in non windows setup when it calls this method.

The fix can be done by simply adding renamed = true; after performing renameTo()
TagsNo tags attached.
planned for version1.2.x
Attached Files

- Relationships

-  Notes
(0000757)
oka (administrator)
2010-02-17 15:26

Your assumption is not correct. The code in "else" block is:

if (isOS2) {
     if (SVNOS2Util.moveFile(src, dst)) {
       renamed = true;
     }
} else if (SVNJNAUtil.moveFile(src, dst)) {
     renamed = true;
}
if (!renamed) {
    // ...
    for (...) {
       if (src.renameTo(dst)) {
           // ...
           return;
       }
    }
}

So, as you may see, either "renamed" flag is set to true (on OS/2 or all other OS if JNA rename succeeded), or rename method exists after successful call to file.renameTo(...) which is done in a for-loop.

We run Subversion python tests suite with SVNKit on Linux and so far there are no problems with rename.

Do you have some other issue to report? Probably exception happens when it is not possible to rename a file (e.g. it is locked by another process)?
(0000758)
nubela (viewer)
2010-02-17 15:53
edited on: 2010-02-17 15:54

I beg to differ:

        if (!isWindows) { //its not windows
            renamed = src.renameTo(dst);
        renamed = true;
        } else {
            // check for os/2 first because on os/2
            // isWindows is also true
            if (isOS2) {
                if (SVNOS2Util.moveFile(src, dst)) {
                    renamed = true;
                }
            } else if (SVNJNAUtil.moveFile(src, dst)) {
                renamed = true;
            } else {
                boolean wasRO = dst.exists() && !dst.canWrite();
                setReadonly(src, false);
                setReadonly(dst, false);
                // use special loop on windows.
                for (int i = 0; i < FILE_CREATION_ATTEMPTS_COUNT; i++) {
                    dst.delete();
                    if (src.renameTo(dst)) {
                        if (wasRO && !isOpenVMS) {
                            dst.setReadOnly();
                        }
                        return;
                    }
                    try {
                        Thread.sleep(100);
                }
            }
                    } catch (InterruptedException e) {
                    }
        }
        if (!renamed) {
            SVNErrorMessage err = SVNErrorMessage.create(SVNErrorCode.IO_ERROR,
                    "Cannot rename file ''{0}'' to ''{1}''", new Object[] {src, dst});
            SVNErrorManager.error(err, Level.FINE, SVNLogType.WC);
        }

If you take a look at the code above, your code will only be executed if isWindows = true. So all non-windows setup can't enter your code, and if it is a linux computer, (which mine is), how can isWindows = true? And given that, how will it pass through the JNA chunk to do SVNJNAUtil.moveFile(src, dst) ?

Of course, I'd love to be proven wrong :)

My case of using SVNKit is a tad special. I am using IKVM (ikmvc to be exact) to convert svnkit to a .NET library which I added as a assembly reference to my mono project. And my simple code worked on Windows, just not on Linux. You can view my stackoverflow question about this here: http://stackoverflow.com/questions/2278485/svnexception-unable-to-rename-file-when-using-svnkit-in-a-ikvmc-ed-library-in-c [^]

Edit: After making that line change, my code worked in Linux as well.

(0000759)
oka (administrator)
2010-02-17 16:16

Yes, this is my mistake, sorry - I gave you a wrong explanation mixing up windows and non-windows code paths. JNA is not used for rename on non-Windows platforms as you have correctly noticed and only File.renameTo(...) is used.

However, using result of the File.renameTo(...) call makes the whole point of this method, isn't it? How else would SVNKit know whether rename have succeeded or have not? This is what said in File.renameTo(...) javadoc:

* @return <code>true</code> if and only if the renaming succeeded;
* <code>false</code> otherwise

So, the question is why renameTo(...) returns "false" in your case. Could it return "false" in case rename succeeds, or does rename actually fails? In case rename operation fails, operation should be interrupted as its results would be unpredictable and will definitely bring the working copy into invalid state. This is why exception is thrown when renameTo(...) returns "false" (which means that file was not renamed as expected).

When converting SVNKit to .NET library, what happens with JDK API calls? Does renameTo(...) get converted to the corresponding .NET API call? What does that .Net method returns? Could it be that it always returns "false"? Then it looks more like a bug in a converter or .Net framework, not SVNKit.
(0000760)
nubela (viewer)
2010-02-17 16:23

No worries ;)

You are right. I didn't realise about the return value of renameTo(). The JDK API should remain all the same. It should be a bug. I will further explore this. Thank you for your time :)
(0000761)
nubela (viewer)
2010-02-17 16:36

added a if (dst.exists()) dst.delete(); and it works too. Thanks oka!
(0000762)
oka (administrator)
2010-02-17 16:54

So, I'm closing this issue for now.

In case you will not manage to fix/workaround converter to generate better code for renameTo method and if you're not happy with the custom version of SVNKit, we could add an option to SVNKit to call dst.delete(...) before renameTo(...)..

- Issue History
Date Modified Username Field Change
2010-02-17 11:08 nubela New Issue
2010-02-17 15:21 oka Status new => assigned
2010-02-17 15:21 oka Assigned To => oka
2010-02-17 15:26 oka planned for version => 1.2.x
2010-02-17 15:26 oka Note Added: 0000757
2010-02-17 15:26 oka Status assigned => closed
2010-02-17 15:26 oka Resolution open => no change required
2010-02-17 15:53 nubela Status closed => feedback
2010-02-17 15:53 nubela Resolution no change required => reopened
2010-02-17 15:53 nubela Note Added: 0000758
2010-02-17 15:54 nubela Note Edited: 0000758
2010-02-17 16:16 oka Note Added: 0000759
2010-02-17 16:23 nubela Note Added: 0000760
2010-02-17 16:36 nubela Note Added: 0000761
2010-02-17 16:54 oka Note Added: 0000762
2010-02-17 16:54 oka Status feedback => closed
2010-02-17 16:54 oka Resolution reopened => no change required


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker