JSR199 FileObjects don't obey general contract of equals.

[Peter Ahé]

I think the problem with URL is more fundamental because it breaks
virtual hosts.  However, in this case, I think you are fine if you
just make sure that you remember the result of safeGetCanonicalFile.
Then the identity of a file object will remain the same, no matter
what happens outside the virtual machine.  This means that you are
safe using them in collections, but that you may, in extreme cases,
end up with two file objects that reference the same actual file but
aren't equal.  However, this would most certainly be the result of
somebody trying to "attack" the program by changing symlinks while the
program is running.  But this is not to prevent elevation of
privileges attacks, merely to ensure that the compiler does not
overwrite existing files (and that the contract of .equals + .hashCode
is obeyed).

Cheers,
Peter

On 6/21/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> You're correct that using getAbsoluteFile is a better backup for when
> getCanonicalFile fails.
>
> However, technically, we still are at risk for failing the general
> contract of equals. I'm
> reminded of the Java Puzzler at JavaOne this year. It involved URLs
> and equallity,
> and the the fact that URLs could sometimes be equal depending on
> whether a
> host's DNS service was available. (I hope I got that right).
>
> I'd hate for JavacFileManager to show up in a puzzler because it
> depends on whether
> NFS was running correctly or nor :-)
>
> That all being said, I agree this is arguably the least perturbation
> of semantics that will
> work most of the time.
>
> -- Jon
>
>
>
> On Jun 20, 2007, at 11:20 PM, Peter Ahé wrote:
>
> > On 6/20/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> >>
> >> On Jun 20, 2007, at 10:49 PM, Peter Ahé wrote:
> >>
> >> > On 6/20/07, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> >> >> So the proposal is the following
> >> >> - fix ZipFileObject equality to use && not ||
> >> >
> >> > That may fix the hashCode issue, but are you sure "foo" and its
> >> > absolute equivalent will remain equal?
> >> >
> >>
> >> That's why I added the 2 bullet in the list -- these were a set to be
> >> taken together,
> >> not alternatives; sorry if that was not clear.
> >
> > Oh, I mistook it for RegularFileObject.  I guess I skimmed the second
> > part.  ZipFileObject.equals is clearly broken.  Ignoring that issue,
> > and focusing on only one thing at a time: I think you need to use
> > getCanonicalFile in RegularFileObject.  However, you may want to
> > consider wrapping it in:
> >
> > File safeGetCanonicalFile(File f) {
> >           try {
> >               return f.getCanonicalFile();
> >           } catch (IOException e) {
> >               return f.getAbsoluteFile();
> >           }
> > }
> >
> > And you may want to ensure this is only calculated once per file
> > object.  However, you must keep the user specified file name around.
> > Otherwise, diagnostics gets messed up.
> >
> > Cheers,
> > Peter
>
>