[jcifs] renameTo

[Michael B Allen]

On Tue, 23 May 2006 11:26:52 -0400
roy-jcifs at xemaps.com wrote:

> On 5/22/06, Michael B Allen <mba2000 at ioplex.com> wrote:
> > No jcifs methods have asyncronous behavior. The closest thing would be
> > SmbFile.copyTo which employs another thread to write while the original
> > thread is reading (or it's the other way around, I can't recall) but
> > the method still doesn't actually return until the copy is complete or
> > an exception occurs.
> 
> So is a renameTo atomic?  Basically I'm trying to hunt down a bug in my code.  There are times when we error out on jcifs renaming a file from ".tmp" to ".eml".  But we end up with two files with both extensions.  It looks like we are gettting an exception during the rename:
> 	jcifs.smb.SmbTransport.send(SmbTransport.java:600)
> 	jcifs.smb.SmbSession.send(SmbSession.java:229)
> 	jcifs.smb.SmbTree.send(SmbTree.java:102)
> 	jcifs.smb.SmbFile.send(SmbFile.java:688)
> 	jcifs.smb.SmbFile.renameTo(SmbFile.java:1779)
> 
> Since I'm seeing two files I am thinking that a renameTo is actually a copyTo and then a delete.  Is this true?  Also it doesn't look like we've been getting this error recently (since march).  Looking at our logs, I see that we switched to jcifs 1.1.9 from some earlier build.  Version 1.1.7 had a fix to the copyTo method.  Is it possible that this fix resolved the issue we were seeing and it could explain why I'm not seeing double files past early march?

Odd. The remameTo method does not use copyTo and it does not copy. It
simply issues an SmbComRename command to the server. So as to whether
or not it's atomic I suppose that probably depends on the server. Look
at the code for jcifs/smb/SmbFile.java:renameTo. It's really simple.

Mike