> However, equals() and hashCode() are not calculated simulataneously, so if the external conditions change between calling the two methods,
> they may disagree.
> Further, a hashCode should not change if the object does not change (and should not change at all if used in some kinds of map).
> It would be safer to fetch the canonical path once, and base the methods on that.
I still think this discussion is getting a bit theoretical for this particular case, but I'll bite. As far as I know, the hashCode() contract says that it might change, if the result of equals changes. Since, in some file systems, the canonical path might change when the file is changed (created/deleted), both equals and hashCode might the change. From our usage, this seems reasonable. From the Javadoc: "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified"
And again, yes, the equals method is needed. It is for example used in RMD to ensure that we do not delete the cwd.
I would be happy to add documentation to specify the contract in FtpFile.equals(), feel free to open an issue for this.