JSR199 FileObjects don't obey general contract of equals.

[Jonathan Gibbons]

My concern would be the unspecified nature of IOExceptions, and  
whether network failure outside the virtual machine could lead the  
code to incorrectly determine that two files were different, when in  
fact they were "symlink-equal" in a part of the path that is no  
longer accessible by virtue of the network failure.

I agree this is an extreme case, and that I have enough of a solution  
that is better than the current code in order to proceed.

-- Jon


On Jun 21, 2007, at 9:39 AM, Peter Ahé wrote:

> 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
>>
>>