Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [stellation-res] File.renameTo()

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: August 24, 2002 7:57 AM
> >To: stellation-res@xxxxxxxxxxxxxxx; Florin Iucha
> >Cc: Stellation
> >Subject: Re: [stellation-res] File.renameTo()
> >
> >
> >On Saturday 24 August 2002 03:32 pm, Florin Iucha wrote:
> >> On Sat, Aug 24, 2002 at 11:15:15AM +0000, Mark C. Chu-Carroll wrote:
> >> > On Saturday 24 August 2002 12:42 pm, Jonathan Gossage wrote:
> >> > > This API is not safe to use on any platform. It will never
> >succeed when
> >> > > a move across file system boundaries is required (e.g.
> >between a local
> >> > > file system and NFS)and on Windows it will fail when
> >trying to move a
> >> > > file from one directory to another. The failure is
> >reported, not by an
> >> > > exception, but simply by returning "false".
> >> >
> >> > I knew about the filesystem restriction, but not the windows
> >restriction.
> >> >
> >> > We didn't consider the filesystem restriction to be a big
> >deal. Since the
> >> > workspace is created and maintained by Stellation, it shouldn't ever
> >> > be crossing filesystems. So moving things around within the workspace
> >> > should never cause a problem.
> >> >
> >> > Windows is a different situation apparently.
> >> >
> >> > > One solution would be to use the Unix mv command, natively
> >under Unix
> >> > > and under Cygwin under Windows. Another, and I feel better
> >solution,
> >> > > would be to implement an internal method that provides the
> >necessary
> >> > > subset of functionality of the mv command.
> >> >
> >> > One solution would be to replace the File.rename with a copy to
> >> > the new location, and delete from the old.
> >>
> >> And penalize the sane architectures that can do that efficiently?
> >
> >Well, we can do the copy/delete when rename returns false, thus making it
> >work everywhere, but not penalizing places where the simple rename
> >works.
> >
> >> Uh-oh... java sucks for I/O more and more...
> >> They rush to add mmap io but cannot provide a sane api to access the
> >> directory structure.
> >
> >Java I/O truly sucks. They've never admitted that a very poor
> >implementation of the lowest-common-denominator of filesystem
> >functionality isn't really good enough. That's part of why we
> >sometimes spawn commands to run external file operations -
> >Java IO just isn't good enough for everything we need.
> >
> >	-Mark
> >
> >
> >--
> >Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center
> >*** The Stellation project: Advanced SCM for Collaboration
> >***		http://www.eclipse.org/stellation
> >*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email:
> >markcc@xxxxxxxxxxx
> >
> >
> >_______________________________________________
> >stellation-res mailing list
> >stellation-res@xxxxxxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/stellation-res

Incidentally the raw Windows I/O does renaming in the same way as Unix does.
It appears to be the Windows JVM that is causing the problems.

Regards

Jonathan Gossage



Back to the top