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
--
Schalk W. Cronjé
@ysb33r
