You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2014/05/17 22:51:08 UTC
[VFS] canRenameTo
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] canRenameTo
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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é <ys...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VFS] canRenameTo
Posted by Schalk Cronjé <ys...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Schalk W. Cronjé
@ysb33r