Hello Schalk,
fully agree with your definition, in fact I have a local version which
reads:
/**
* Queries the object if a rename to the filename of {@code newfile}
* is possible.
* <P>
* This default implementation does not attach the file and return
* false in any of the following cases:
* <ul>
* <li>It is not the same file system instance</li>
* <li>The filesystem does not have the {@link Capability#RENAME}</li>
* <li>If both are the same {@link FileObject} instance</li>
* </ul>
* <P>
* It does not use {@link #isSameFile(FileObject)} to check if it is
actually
* the same file, because this would require an {@link #attach()}.
*
* @param newfile the new filename
* @return true if rename is possible
*/
@Override
public boolean canRenameTo(final FileObject newfile)
{
if (!fs.hasCapability(Capability.RENAME))
{
return false;
}
if (fs != newfile.getFileSystem())
{
return false;
}
if (this == newfile)
{
return false;
}
//if (isSameFile(newfile))
// return false;
return true;
}
The isSameFile() has a similiar problem (I would add the "this == other" check
to the default implementation (actually before attaching and before
doIsSameFile).
Greetings
Bernd
Am Sun, 18 May 2014 09:12:33 +0100
schrieb Schalk Cronjé <ysb...@gmail.com>:
> I concur.
>
> Firstly it returns a boolean and it implies is about asking a
> question, not about returning a property from a fie or filesystem.
> From a API consume point of view I would not any exception to be
> thrown, just to be told whether the operation is possible or not.
> Thus the HdfsFileObject implementation is unexpected behaviour and
> should be removed.
>
> The AbstractFileObject implementation is lacking too. From an
> provider implementer's point of view I would expect this to do a
> couple of things for me.
>
> * If I did not specify RENAME capability, canRenameTo should always
> return false
> * If I did specify RENAME capability, canRenameTo's default
> behaviour would be to check for same filesystem and whether it is the
> same file object.
> * If I decide that the default behaivour is not sufficient, then I
> can choose to override (but I should still not throw an exception)
>
>
> It can also be debated whether canRenameTo should actually have been
> protected. I know we won't change visibility as it would break the
> API, however I would think it have as limited usefulness for a
> consumer of the API. As the latter I would rather call moveTo. The
> only use case that I can think of in this context is where I might
> have a large folder system and I want to check beforehand whether the
> move operation will be expensive (lots of copying) or atomic (simple
> rename).
>
> Regards.
>
> On 17/05/2014 21:51, Bernd Eckenfels wrote:
> > Hello,
> >
> > today there are only two canRenameTo implementations in VFS2, the
> > AbstractFileObject one which does just check if the file is on the
> > same VFS filesystem instance and HdfsFileObject which overwrites
> > this with UnsupportedOperation.
> >
> > For the HdfsFileObject I think it is best to remove this special
> > version [VFS-523], as no other file system provider (even the ones
> > which do not have RENAME Capability) do this.
> >
> > However I wonder how usefull the canRenameTo. It does neighter
> > check if it is the same file, if the provider does support rename
> > nor are there any smarter specific implementations.
> >
> > For example for the LocalFileObject I could imagine to actually
> > check if it is on the same OS file system.
> >
> > I guess it is hard to know if a rename across multiple VFS
> > filesystems (even when they point to the same backend store) is
> > possbiel, so it is ok to always return false if the filesystem
> > instances differ.
> >
> > Gruss
> > Bernd
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
