commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Schalk Cronjé <>
Subject Re: [VFS] canRenameTo
Date Sun, 18 May 2014 08:12:33 GMT
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).


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:
> For additional commands, e-mail:

Schalk W. Cronjé

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message