Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 74.125.78.148 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=hBLXM1Camv0aDu/6U8LaCzoucumz34zB6LHQ+CdoqSHLawLqwvw3ZmCyybDH2QCGB3
         sCXqW01Pad5SBYN5yvuRqb1T6TEBx3A03xejR1aGQMeaQDXrjIBvzv9rR5ACVQxZmbLe
         IO4c6+5SgTVENrqPTIF5FWHX6Iomg0OKo57kg=
Message-ID: <48CF7C33.2020103@gmail.com>
Date: Tue, 16 Sep 2008 10:28:19 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Created: (HARMONY-5979) [classlib][luni] -
 File.deleteOnExit
 has different behaviours with RI
References: <1710486863.1221105524325.JavaMail.jira@brutus>
	 <48C8D5A3.8010806@gmail.com>
 <48C8E6C8.1000506@gmail.com>	 <48C91A10.9010002@gmail.com>
 <48C9D001.3000303@gmail.com>
 <c8963150809152137w4e6c7094n1fc01f7a57764fbf@mail.gmail.com>
 <48CF3C1E.8070207@gmail.com>
In-Reply-To: <48CF3C1E.8070207@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Regis wrote:
> I double check the spec, it(deleted in the reverse order) is mentioned
> in Java6, not Java5.
> So we should only fix it on Java6 branch?

No, I think the spec was clarified to describe the behavior that already
existed in Java 5.  I suggest you fix it in there.

Regards,
Tim

> Jim Yu wrote:
>> Hi Regis,
>> IMO, RI's behavior is reasonable according to the spec which says
>> "Files (or
>> directories) are deleted in the reverse order that they are
>> registered."  So
>> it is correct for RI to execute deleteOnExit() methods in the reverse
>> order that you invoked in the test case.
>> 2008/9/12 Regis <xu.regis@gmail.com>
>>
>>> Actually Harmony delete files by the order of lenght of file path,
>>> the file
>>> with
>>> longest path would be deleted first (not the order added to the
>>> list). So
>>> Harmony
>>> can always successfully delete all marked files. The code is from
>>> DeleteOnExit.java:
>>>
>>>        public static void deleteOnExit() {
>>>        java.util.Collections.sort(deleteList,
>>>                new java.util.Comparator<String>() {
>>>                    public int compare(String s1, String s2) {
>>>                        return s2.length() - s1.length();
>>>                    }
>>>                });
>>>                for (int i = 0; i < deleteList.size(); i++) {
>>>                        String name = deleteList.elementAt(i);
>>>                        new File(name).delete();
>>>                }
>>>        }
>>>
>>> I think it's smarter than RI.
>>>
>>>
>>> Tim Ellison wrote:
>>>
>>>> Regis wrote:
>>>>
>>>>> The behavior of RI may leave some files marked as deleteOnExit
>>>>> after vm
>>>>> exit, so
>>>>> it's confused why marked files wasn't deleted after vm exit, and it
>>>>> doesn't match the
>>>>> semantic of this method. Maybe it's RI's bug?
>>>>>
>>>> In general you can't tell what order will succeed in deleting all the
>>>> files because you can't accurately determine the file system
>>>> dependencies between them.
>>>>
>>>> Based on your test program, Harmony attempts the deletion in the order
>>>> the files were added to the list, and the RI attempts them in the
>>>> reverse order.  I was just suggesting we modify Harmony to also do
>>>> reverse order so any application that assumes this will continue to
>>>> work.
>>>>
>>>> I agree it is a compatibility rather than spec' compliance issue
>>>> though.
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>  Tim Ellison wrote:
>>>>>> I suggest Harmony changes to match the behavior of the RI in this
>>>>>> case.
>>>>>>
>>>>>> It will avoid unnecessary incompatibilities and seems logical for
>>>>>> programs that create dir and mark for deleteOnExit, then create files
>>>>>> and mark for deleteOnExit etc. as they go.
>>>>>>
>>>>>> Regards,
>>>>>> Tim
>>>>>>
>>>>>> Regis Xu (JIRA) wrote:
>>>>>>
>>>>>>> [classlib][luni] - File.deleteOnExit has different behaviours
>>>>>>> with RI
>>>>>>>  ---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Key: HARMONY-5979 URL:
>>>>>>> https://issues.apache.org/jira/browse/HARMONY-5979 Project: Harmony
>>>>>>> Issue Type: Bug Components: Classlib Affects Versions: 5.0M7
>>>>>>> Reporter: Regis Xu Fix For: 5.0M8
>>>>>>>
>>>>>>>
>>>>>>> consider the following test:
>>>>>>>
>>>>>>> File f1 = new File("d1"); f1.mkdirs(); File f2 = new File("d1/d2");
>>>>>>> f2.mkdirs(); File f3 = new File("d1/d2/f1");
>>>>>>>
>>>>>>> f3.createNewFile();
>>>>>>>
>>>>>>> f3.deleteOnExit(); f2.deleteOnExit(); f1.deleteOnExit();
>>>>>>>
>>>>>>> RI leaves d1 and d2, while Harmony deletes all of the three
>>>>>>> files. If
>>>>>>> we change the order of invoke deleteOnExit to f2.deleteOnExit();
>>>>>>> f3.deleteOnExit(); f1.deleteOnExit(); RI leaves d1, Harmony also
>>>>>>> detete all the three files. It seems RI delete files in the reverse
>>>>>>> order of invoking deleteOnExit. And spec doesn't mention which order
>>>>>>> should be used, is it a non-bug difference, or we should fix it
>>>>>>> to be
>>>>>>> compatible with RI?
>>>>>>>
>>>>>>>
>>>>>>>
>>
>>
>