Delete multiple file and multiple directory

[somkiat puisungnoen]

My problem :

I want to delete all file/ derectory in current directory, BUT i don't know how to do ..

How to do that ?

[Ernest Friedman-Hill]

Use java.io.File.listFiles() to get an array of File objects representing every file in a directory. For each one, check isDirectory(). If it returns false, you've got a file, and can just delete it. Otherwise, it's another directory, and you have to recursively delete its contents before deleting it.

[Ko Ko Naing]

Originally posted by Ernest Friedman-Hill:
Use java.io.File.listFiles() to get an array of File objects representing every file in a directory. For each one, check isDirectory(). If it returns false, you've got a file, and can just delete it. Otherwise, it's another directory, and you have to recursively delete its contents before deleting it.

Mr.Ernest,
Recursive deletion like this way is pretty exhaustic, I feel... We have to keep track of all the directories... Even after we delete all the contents inside a directory, we need to get back to its parent directory and delete the original directory. If the directories are located in a very depth way, it's more exhaustic...

Kind of exhaustic depth-first search...

I'm wondering if there is any other way to accomplish somkiat's requirements...

Thanks

[Ian Darwin]

Recursive deletion like this way is pretty exhaustic, I feel... We have to keep track of all the directories... Even after we delete all the contents inside a directory, we need to get back to its parent directory and delete the original directory. If the directories are located in a very depth way, it's more exhaustic...

Kind of exhaustic depth-first search...

I'm wondering if there is any other way to accomplish somkiat's requirements...

Well, recursion isn't really hard, once you understand it. And every Java developer should But meanwhile...

Depending on the operating system, you could also use the system utilities; something like this for UNIX or LInux:

 Runtime.getRuntime().exec("rm -r -f  " + thatOldDirectory); 

[ October 13, 2004: Message edited by: Ian Darwin ]

[Ko Ko Naing]

Yes, Mr.Darwin, calling native function using exec() method is a better alternative, since we don't need to do recursion by ourselves and the options of "rm" command will take care of it for us...

Thanks a lot for ur tips as well...

[Tony Morris]

What made you arrive at the conclusion that a native call is the better solution? Seldom is the best solution arrived at simply because the alternatives 'too hard'.

Native calls are a last resort; they have been provided for when the JVM can't achieve the intended result (often because the result is platform-dependant). Since when did deleting a directory become platform-dependant?

Sounds like a red herring to me.

[Stefan Wagner]

Delete subir after the files:

if (f.isDir ()) 
{
   deleteAllIn (f);
}
f.delete ();

- real hard stuff.

[Ko Ko Naing]

Originally posted by Stefan Wagner:
Delete subir after the files:

if (f.isDir ()) 
{
   deleteAllIn (f);
}
f.delete ();

- real hard stuff.

Imagine if you have several steps deep down into the tree? Depth-first search is exhaustic, as we have learnt in bachelor degree...

It's true that platform-independent issue matters, but we can certainly check the platform before using the exec() in our application... So instead of thining how to dela with multiple steps in directory tree, we can easily pick up a native call and just use it in exec()...

Just my 2 cents...

[Stefan Wagner]

You may convert every recursive algorithm to a non-recursive one.
Which wasn't the question.

I don't know the system-call to delete a subdirectory on a Mac, on Windows, on future-versions of windows, of mobile-phones ...., washing machines, and other java-devices...

[Ernest Friedman-Hill]

Originally posted by Ko Ko Naing:

So instead of thining how to dela with multiple steps in directory tree, we can easily pick up a native call and just use it in exec()...

I'm not aware of an OS that has "delete a file tree" as a kernel primitive. It's generally a user-space program (rm on unix, deltree on windows). That external program has no choice but to recurse (or iterate, as Stefan points out) though all the files, exactly as you would in Java. The price you pay for that "convenience" is extra Java code to choose a command based on the OS, plus the overhead of executing a separate process, to do something which will be no faster in native code than in Java (since the runtime is going to be dominated by disk I/O performance.)

This is the weirdest argument I've seen in a long time.