Hello,
I can't delete the file temp.mdb
Is it because its a .mdb file? How do I delete it?
I tried the following code:
File local =new File("temp.mdb");
System.out.println(local.delete());
The result I get is false and the file is still there!
Please help me!
> Hy,
>
> I want to know about SRV Record configuration to work
> with Solaris 8, Iplanet 5.2 and MS Active Directory.
>
> Can anybody help me? Any suggestions? Thanks in
> advance
>
>
> By,
>
> chernandez@une.edu.ve
Yeh I've got a suggestion: Post your question in another forum, that is at least remotely related to your problem, rather than hijacking someone elses thread in an unrelated one
> > System.gc();
> System.out.println(local.delete());
> System.out.println(local.exists());
>
>
> Returns:
>
> false
> true
>
> File is still there. Yes its the correct path.
Something's got the file open, then. JDBC connection? Is MSAccess open on it? Windows Explorer? Can you delete the file manually?
> You're holding a strong reference to the file, so the
> system cannot delete it.
> Try:
>
>
> code]
> System.out.println(new File("temp.mdb").delete());
> [/code]
Not convinced that's true, but I'm on a *nix box so the rules are different anyway. Have you got a working test case that proves keeping references to File objects keeps the actual file-on-disk alive?
> > You're holding a strong reference to the file, so
> the
> > system cannot delete it.
> > Try:
> >
> >
> > code]
> > System.out.println(new File("temp.mdb").delete());
> > [/code]
>
> Not convinced that's true, but I'm on a *nix box so
> the rules are different anyway. Have you got a
> working test case that proves keeping references to
> File objects keeps the actual file-on-disk alive?
Well, it seems to me that this whole topic is a test case to prove my point. Let's see what the OP has to say about my solution.
Best regards.
Message was edited by:
Danniel_Willian
> > > You're holding a strong reference to the file,
> so
> > the
> > > system cannot delete it.
> > > Try:
> > >
> > >
> > > code]
> > > System.out.println(new
> File("temp.mdb").delete());
> > > [/code]
> >
> > Not convinced that's true, but I'm on a *nix box
> so
> > the rules are different anyway. Have you got a
> > working test case that proves keeping references
> to
> > File objects keeps the actual file-on-disk alive?
>
> Well, it seems to me that this whole topic is a test
> case to prove my point. Let's see what the OP has to
> say about my solution.
>
> Best regards.
>
> Message was edited by:
> Danniel_Willian
Just seems odd, I've never heard of a File object keeping a file locked, nor is there any mention of it in the javadocs for java.io.File, and whenever this question comes up - which is fairly often - nobody has ever mentioned it before. Doesn't make any sense, either, and I know I've managed to delete files and re-create them using the same File object in the past. Do you have any references to this behaviour?
> Just seems odd, I've never heard of a File object
> keeping a file locked, nor is there any mention of it
> in the javadocs for java.io.File, and whenever this
> question comes up - which is fairly often - nobody
> has ever mentioned it before. Doesn't make any sense,
> either, and I know I've managed to delete files and
> re-create them using the same File object in the
> past. Do you have any references to this behaviour?
Have you ever wondered why whenever this question comes up
- which is fairly often - people always suggest running System.gc()
before deletion?
> > Just seems odd, I've never heard of a File object
> > keeping a file locked, nor is there any mention of
> it
> > in the javadocs for java.io.File, and whenever
> this
> > question comes up - which is fairly often - nobody
> > has ever mentioned it before. Doesn't make any
> sense,
> > either, and I know I've managed to delete files
> and
> > re-create them using the same File object in the
> > past. Do you have any references to this
> behaviour?
>
> Have you ever wondered why whenever this question
> comes up
> - which is fairly often - people always suggest
> running System.gc()
> before deletion?
It was my understanding that there was a bug in certain JVMs, related to streams being left open; that's always been the consensus, and misc. bug reports confirm this. Do you have any references to the contrary? I'm actually interested, not looking for an argument
> It was my understanding that there was a bug in
> certain JVMs, related to streams being left open;
> that's always been the consensus, and misc. bug
> reports confirm this. Do you have any references to
> the contrary? I'm actually interested, not looking
> for an argument.
George,
I don't know if this is some kind of bug in certain JVM implementations,
or if this is a bug between the JVM and the Windows file locking system.
You are right when you say that, following strictly the java.io.File specs,
there is nothing telling that holding a strong reference to a File object
will block that file from deletion. All I know, through my experience with
files, is that whenever I hold a strong reference to a File I can't get to delete
that file.
Best regards.
> > It was my understanding that there was a bug in
> > certain JVMs, related to streams being left open;
> > that's always been the consensus, and misc. bug
> > reports confirm this. Do you have any references
> to
> > the contrary? I'm actually interested, not looking
> > for an argument.
>
> George,
>
> I don't know if this is some kind of bug in certain
> JVM implementations,
> or if this is a bug between the JVM and the Windows
> file locking system.
> You are right when you say that, following strictly
> the java.io.File specs,
> there is nothing telling that holding a strong
> reference to a File object
> will block that file from deletion. All I know,
> through my experience with
> files, is that whenever I hold a strong reference to
> a File I can't get to delete
> that file.
>
> est regards.
Hmmmm. The following test case passes every time (on Windows) - note how I maintain the reference
public void testFileDeletesWhenReferenceHeld() throws Exception {
// "file.txt" created by an external process
File file = new File("C:\\file.txt");
assertTrue(file.exists());
assertTrue(file.delete());
assertFalse(file.exists());
}
It makes no sense that File references would make a difference anyway, it's not them that actually carry out disk I/O, it's the underlying FileSystem object
> Have you ever wondered why whenever this question
> comes up
> - which is fairly often - people always suggest
> running System.gc()
> before deletion?
Yes, I have. My deduction was that the garbage collection would run the finalizer of some object that was locking the file in some way, some object to which all references had been discarded. My guess for that object was an input or output stream that had not been closed but had been abandoned by the program.
If the hypothesis that the existence of a strongly-referenced File object corresponding to a file made it impossible to delete said file, then the File.delete() method would never, ever, work. You can't call the delete() method without a strongly-referenced object to call it on. So therefore I would classify that hypothesis as false.
> You're holding a strong reference to the file, so the
> system cannot delete it.
> Try:
> > System.out.println(new File("temp.mdb").delete());
>
Nope. Nothing to do with it. A File is just a holder for a filename and has no connection to the outside world. Never seen that idiom, let alone had to use it, in ten years of Java.
Hello again,
Thank you very much in your interest in solving this topic. I managed to delete the file because I had a connection locked on the file so I had to close it before .delete(). Anyway this didn't solve my real problem because I also want to delete a file outside my application on the harddrive. This doesnt seem to work either and now Im absolutely sure that I have no connection and no program running on it. Please see my whole java file code:
package test;
import java.io.*;
public class Main {
public Main() {
}
public static void main(String[] args) {
String PathName = "C:\\Program Files\\test\\temp.doc";
File tempFile = new File(PathName);
System.out.println(tempFile.getPath());
System.out.println(tempFile.exists());
System.out.println(tempFile.delete());
System.exit(0);
}
}
The wierd thing is that I get the following output:
C:\Program Files\test\temp.doc
true
true
It says true and the file is still there! How can that be possible?
Can the problem be that Im running Windows Vista?
> Hello again,
>
> Thank you very much in your interest in solving this
> topic. I managed to delete the file because I had a
> connection locked on the file so I had to close it
> before .delete().
Even though you were specifically asked that, and specifically stated it wasn't the case? When this problem comes up, 99% of the time it's because of that, and 98% of the time the poster insists it isn't!
> Anyway this didn't solve my real
> problem because I also want to delete a file outside
> my application on the harddrive. This doesnt seem to
> work either and now Im absolutely sure that I have no
> connection and no program running on it. Please see
> my whole java file code:
>
> > package test;
>
> import java.io.*;
>
> public class Main {
>
> lic Main() {
>}
>
> public static void main(String[] args) {
> String PathName = "C:\\Program
> Files\\test\\temp.doc";
>File tempFile = new File(PathName);
> System.out.println(tempFile.getPath());
> System.out.println(tempFile.exists());
>
> System.out.println(tempFile.delete());
> System.exit(0);
>
>
>
> The wierd thing is that I get the following output:
>
> C:\Program Files\test\temp.doc
> true
> true
>
> It says true and the file is still there! How can
> that be possible?
>
> Can the problem be that Im running Windows Vista?
Again, probably something has a handle on the file. Got a text editor watching it? Is it visible in Explorer? Did MSWord or whatever had it open actually close down, or is there some rogue process hanging around keeping the file open?
> Have you ever wondered why whenever this question comes up
> - which is fairly often - people always suggest
> running System.gc() before deletion?
I've never wondered it. There are people who suggest running the gc() for any problem they encounter.
And about finalizers, as far as I've understood there's no guarantee that gc() would cause the finalize()rs to be run...
> > Have you ever wondered why whenever this question
> comes up
> > - which is fairly often - people always suggest
> > running System.gc() before deletion?
>
> I've never wondered it. There are people who suggest
> running the gc() for any problem they encounter.
But it is a known workaround for a similar problem to this, all the same
> And about finalizers, as far as I've understood there's no guarantee that gc() would > > > cause the finalize()rs to be run...
Also true, but despite what documentation tells us, this workaround really does solve a particular problem. There are enough examples of it being used for it not to be discounted, [url=http://blogs.codehaus.org/people/vmassol/archives/001036_id_love_reusable_ant_tasks.html]such as Ant[/url] and various other Apache projects. Pretty sure I've seen it in the Eclipse source, too. Plus, it worked reliably for me
