harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: [jira] Created: (HARMONY-5979) [classlib][luni] - File.deleteOnExit has different behaviours with RI
Date Tue, 16 Sep 2008 04:54:54 GMT
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?

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

Mime
View raw message