file delete returns false even though file exists file canRead file canWrite file canExecute all return true

Question

I m trying to delete a file  after writing something in it  with FileOutputStream  This is the code I use for writing   private void writeContent File file  String fileContent        FileOutputStream to      try           to   new FileOutputStream file           to write fileContent getBytes             to flush            to close          catch  FileNotFoundException e               TODO Auto-generated catch block         e printStackTrace          catch  IOException e               TODO Auto-generated catch block         e printStackTrace              As it is seen  I flush and close the stream  but when I try to delete  file delete   returns false   I checked before deletion to see if the file exists  and  file exists    file canRead    file canWrite    file canExecute   all return true  Just after calling these methods I try file delete   and returns false   Is there anything I ve done wrong

User · Answer

FOR Eclipse NetBeans   Restart your IDE and run your code again this is only trick work for me after one hour long struggle   Here is my code   File file   new File  file-path    if file exists       if file delete          System out println  Delete          else          System out println  not delete            Output   Delete

User · Answer

The problem could be that the file is still seen as opened and locked by a program  or maybe it is a component from your program that it had been opened in  so you have to ensure you use the dispose   method to solve that problem   i e  JFrame frame       frame dispose

User · Answer

Hopefully this will help  I came across similar problem where i couldn t delete my file after my java code made a copy of the content to the other folder  After extensive googling  i explicitly declared every single file operation related variables and called the close   method of each file operation object  and set them to NULL  Then  there is a function called System gc    which will clear up the file i o mapping  i m not sure  i just tell what is given on the web sites    Here is my example code   public void start         File f   new File this archivePath          this currentFile getName         this Copy this currentFile  f        if  this currentFile canWrite             System out println  Write protected file                this currentFile getAbsolutePath              return              boolean ok   this currentFile delete        if ok    false           System out println  Failed to remove     this currentFile getAbsolutePath             return           private void Copy File source  File dest  throws IOException       FileInputStream fin      FileOutputStream fout      FileChannel cin   null  cout   null      try           fin   new FileInputStream source           cin   fin getChannel            fout   new FileOutputStream dest           cout   fout getChannel             long size   cin size            MappedByteBuffer buf   cin map FileChannel MapMode READ ONLY  0  size            cout write buf           buf clear            buf   null           cin close            cin   null           fin close            fin   null           cout close            cout   null           fout close            fout   null           System gc           catch  Exception e           this message   e getMessage            e printStackTrace

User · Answer

It was pretty odd the trick that worked  The thing is when I have previously read the content of the file  I used BufferedReader  After reading  I closed the buffer   Meanwhile I switched and now I m reading the content using FileInputStream  Also after finishing reading I close the stream  And now it s working   The problem is I don t have the explanation for this    I don t know BufferedReader and FileOutputStream to be incompatible

User · Answer

There was a problem once in ruby where files in windows needed an  fsync  to actually be able to turn around and re-read the file after writing it and closing it  Maybe this is a similar manifestation  and if so  I think a windows bug  really

User · Answer

If you are working in Eclipse IDE  that could mean that you haven t close the file in the previous launch of the application  When I had the same error message at trying to delete a file  that was the reason  It seems  Eclipse IDE doesn t close all files after termination of an application

User · Answer

I had the same problem on Windows  I used to read the file in scala line by line with  Source fromFile path  getLines     Now I read it as a whole with  import org apache commons io FileUtils       encoding is null for platform default val content readFileToString new File path  null asInstanceOf String     which closes the file properly after reading and now  new File path  delete   works

User · Answer

if file delete   is sending false then in most of the cases your Bufferedreader handle will not be closed  Just close and it seems to work for me normally

User · Answer

None of the solutions listed here worked in my situation  My solution was to use a while loop  attempting to delete the file  with a 5 second  configurable  limit for safety   File f   new File   path to file     int limit   20    Only try for 5 seconds  for safety while  f delete    amp  amp  limit  gt  0       synchronized this           try               this wait 250     Wait for 250 milliseconds           catch  InterruptedException e                e printStackTrace                        limit--      Using the above loop worked without having to do any manual garbage collecting or setting the stream to null  etc

User · Answer

You have to close all of the streams or use try-with-resource block  static public String head File file  throws FileNotFoundException  UnsupportedEncodingException  IOException       final String readLine      try  FileInputStream fis   new FileInputStream file               InputStreamReader isr   new InputStreamReader fis   UTF-8                LineNumberReader lnr   new LineNumberReader isr                 readLine   lnr readLine              return readLine

User · Answer

There is no reason you should not be able to delete this file  I would look to see who has a hold on this file  In unix linux  you can use the lsof utility to check which process has a lock on the file  In windows  you can use process explorer   for lsof  it s as simple as saying   lsof  path and name of the file   for process explorer you can use the find menu and enter the file name to show you the handle which will point you to the process locking the file    here is some code that does what I think you need to do   FileOutputStream to   try       String file     tmp will delete txt       to   new FileOutputStream file        to write new String  blah blah   getBytes         to flush        to close        File f   new File file       System out print f delete       catch  FileNotFoundException e           TODO Auto-generated catch block     e printStackTrace      catch  IOException e           TODO Auto-generated catch block     e printStackTrace        It works fine on OS X  I haven t tested it on windows but I suspect it should work on Windows too  I will also admit seeing some unexpected behavior on Windows w r t  file handling

User · Answer

Another corner case that this could happen  if you read write a JAR file through a URL and later try to delete the same file within the same JVM session   File f   new File   tmp foo jar    URL j   f toURI   toURL     URL u   new URL  jar     j      META-INF MANIFEST MF    URLConnection c   u openConnection        open a Jar entry in auto-closing manner try  InputStream i   c getInputStream              just read some stuff  for demonstration purposes only     byte   first16   new byte 16       i read first16       System out println new String first16                  i is now closed  so we should be good to delete the jar  but    System out println f delete            says false      Reason is that the internal JAR file handling logic of Java  tends to cache JarFile entries      inner class of  JarURLConnection  that wraps the actual stream returned by  getInputStream     class JarURLInputStream extends FilterInputStream       JarURLInputStream InputStream var2            super var2              public void close   throws IOException           try               super close              finally                   if  getUseCaches    is set   jarFile  won t get closed               if   JarURLConnection this getUseCaches                      JarURLConnection this jarFile close                                      And each JarFile  rather  the underlying ZipFile structure  would hold a handle to the file  right from the time of construction up until close   is invoked   public ZipFile File file  int mode  Charset charset  throws IOException                   jzfile   open name  mode  file lastModified    usemmap                          private static native long open String name  int mode  long lastModified                                  boolean usemmap  throws IOException    There s a good explanation on this NetBeans issue     Apparently there are two ways to  fix  this    You can disable the JAR file caching - for the current URLConnection  or for all future URLConnections  globally  in the current JVM session   URL u   new URL  jar     j      META-INF MANIFEST MF    URLConnection c   u openConnection        for only c c setUseCaches false       globally  for some reason this method is not static     so we still need to access it through a URLConnection instance    c setDefaultUseCaches false     HACK WARNING   You can manually purge the JarFile from the cache when you are done with it  The cache manager sun net www protocol jar JarFileFactory is package-private  but some reflection magic can get the job done for you   class JarBridge        static void closeJar URL url  throws Exception               JarFileFactory jarFactory   JarFileFactory getInstance            Class lt   gt  jarFactoryClazz   Class forName  sun net www protocol jar JarFileFactory            Method getInstance   jarFactoryClazz getMethod  getInstance            getInstance setAccessible true           Object jarFactory   getInstance invoke jarFactoryClazz               JarFile jarFile   jarFactory get url           Method get   jarFactoryClazz getMethod  get   URL class           get setAccessible true           Object jarFile   get invoke jarFactory  url               jarFactory close jarFile           Method close   jarFactoryClazz getMethod  close   JarFile class           close setAccessible true             noinspection JavaReflectionInvocation         close invoke jarFactory  jarFile               jarFile close              JarFile  jarFile  close                and in your code      i is now closed  so we should be good to delete the jar JarBridge closeJar j   System out println f delete            says true  phew     Please note  All this is based on Java 8 codebase  1 8 0 144   they may not work with other   later versions

User · Answer

Before trying to delete rename any file  you must ensure that all the readers or writers  for ex  BufferedReader InputStreamReader BufferedWriter  are properly closed   When you try to read write your data from to a file  the file is held by the process and not released until the program execution completes  If you want to perform the delete rename operations before the program ends  then you must use the close   method that comes with the java io   classes

User · Answer

the answer is when you load the file  you need apply the  close  method  in any line of code  works to me

User · Answer

I tried this simple thing and it seems to be working   file setWritable true   file delete      It works for me     If this does not work try to run your Java application with sudo if on linux and as administrator when on windows  Just to make sure Java has rights to change the file properties

User · Answer

As Jon Skeet commented  you should close your file in the finally       block  to ensure that it s always closed  And  instead of swallowing the exceptions with the e printStackTrace  simply don t catch and add the exception to the method signature  If you can t for any reason  at least do this   catch IOException ex        throw new RuntimeException  Error processing file XYZ   ex       Now  question number  2   What if you do this       to close    System out println  Please delete the file and press  lt enter gt  afterwards     System in read          Would you be able to delete the file   Also  files are flushed when they re closed  I use IOUtils closeQuietly       so I use the flush method to ensure that the contents of the file are there before I try to close it  IOUtils closeQuietly doesn t throw exceptions   Something like this       try               to flush      catch IOException ex        throw new CannotProcessFileException  whatever   ex     finally       IOUtils closeQuietly to       So I know that the contents of the file are in there  As it usually matters to me that the contents of the file are written and not if the file could be closed or not  it really doesn t matter if the file was closed or not  In your case  as it matters  I would recommend closing the file yourself and treating any exceptions according

User · Answer

Another bug in Java  I seldom find them  only my second in my 10 year career  This is my solution  as others have mentioned   I have nether used System gc    But here  in my case  it is absolutely crucial  Weird  YES   finally       try               in close            in   null          out flush            out close            out   null          System gc              catch  IOException e                logger error e getMessage             e printStackTrace

[java] file.delete() returns false even though file.exists(), file.canRead(), file.canWrite(), file.canExecute() all return true

Examples related to java

Examples related to file

Examples related to fileoutputstream