harmony-dev mailing list archives

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


-- 
Best Regards,
Jim, Jun Jie Yu

China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message