Hi,
I have attached a patch on JIRA, anyone want to try it?
Best Regards,
Regis.
Tim Ellison wrote:
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 <[EMAIL PROTECTED]>
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?
