File delete

hi
i want to delete files in a directory,
i tried code like this but that is not usefull,the folder is still exsit there
File dwnldDir = new File(project.GetLeft.GlobalConstants.MAIN_DOWNLOAD_DIRECTORY, dwnldID);
//this will return name directory
          File[] innerFiles = dwnldDir.listFiles();
          for(int i=0; i < innerFiles.length; i++)
               innerFiles.delete();
          }//end for
then i tried this too,
boolean success = (new File("innerFiles[i]")).delete();
if (!success) {   
System.out.println("file not deleted");
but it shows "file not deleted "for every file.
is there any problem with file permission,
who can i change file permission in java.
i created the directory and file by dowmloaded java class"MD5".
when i check the permission it shows read only;
plz help me
thank u
shilja

Hi,
As you have mentioned .... you have read only access ... you can read it but you can't delete it.
It depend on which operating system you are ....
on unix systems you can use "chmod +w <file_name> " this will again depend if you have permissions.
on windows you can right click and check for properties ... there is check box <read only> you can deselect it.
Hope this will work

Similar Messages

  • Trying to delete file from trash but get this: The operation can't be completed because the item "File name" is in use. All other files delete except this one. Please help

    Trying to delete file from trash but get this: The operation can’t be completed because the item “File name” is in use. All other files delete except this one. Please help

    Maybe some help here:
    http://osxdaily.com/2012/07/19/force-empty-trash-in-mac-os-x-when-file-is-locked -or-in-use//

  • HT2674 I have an iMac purchased in May 2011.  OSX Lion 10.7.3.  I deleted backup file from the external hard drive. Now, the trash can will not empty some of the files deleted.  File folder: "Core Services" contains a locked file: "boot.efi".  It will not

    I have an iMac purchased in May 2011.  OSX Lion 10.7.3.  I deleted backup file from the external hard drive which operates from Time Machine.
    Now, the trash can will not empty some of the files deleted from the backup harddrive.
    The trash contains-- File folder: "Core Services" which contains a locked file: "boot.efi". 
    It will not delete.
    How do I get the trash can empty of these files?

    Yes, the Old Master file has a folder for each year where I find all photos from that specific year. I am attaching a screen shot of the file.
    In the meantime i have managed to download all photos (it did not download any video files though in mpg, avi, 3gp, m4v,mp4 and mov format) to a new iphoto library. Unfortunately the photos are quite mixed and often doubled up. I ma considering to purchase iphoto library which checks all duplicates in iphoto. this will save me a lot of time. What do you think?

  • File.delete() and File.deleteOnExit() doesn't work consistently..

    I am seeing some odd behavior with trying to delete files that were opened. Usually just doing new File("file.txt").delete() would work. However, in this case, I have created an input stream to the file, read it in, saved it to another location (copied it), and now I am trying to delete it.
    The odd thing is, in my simple application, the user can work with one file at a time, but I move "processed" files to a lower pane in a swing app. When they exit it, it then archives all the files in that lower pane. Usually every file but the last one opened deletes. However, I have seen odd behavior where by some files don't delete, sometimes all of them wont delete. I tried the deleteOnExit() call which to me should be done by the JVM after it has released all objects such that they don't matter and the JVM ignores any object refs and directly makes a call (through JNI perhaps) to the underlying OS to delete the file. This doesn't work either.
    I am at a loss as to why sometimes some files delete, and other times they don't. In my processing code, I always close the input stream and set its variable to null. So I am not sure how it is possible a reference could still be held to the object representing the file on disk.

    and then, in the other class
      public int cdplayerINIToMMCD(File aDatabase, String thePassword) throws IllegalArgumentException {
         /*---------DATA---------*/
         String dbLogin, dbPassword;
         JFileChooser fc;
         INIFileFilter ff;
         int dialogReturnVal;
         String nameChosen;
         File INIFile;
         ProgressMonitor progressMonitor;
         BufferedReader inFileStream;
         String oneLine;
         int totalLines = 0;
         int linesParsed = 0;
         boolean openDBResult;
         int hasPassword;
         if ((aDatabase == null) || (!aDatabase.exists()) ||
            (FileManagement.verifyMMCD(aDatabase) == FileManagement.VERIFY_FAILED)) {
            throw new IllegalArgumentException();       
         else { 
            currentDB = aDatabase;
            if(thePassword == null) {
              dbPassword = "";
            else { dbPassword = thePassword; }
            dbLogin = dbPassword; //For MSAccess dbLogin == dbPassword
         //Ask the user for the cdplayer.ini file.
         //Create a file chooser
         if (System.getProperty("os.name").indexOf("Windows") > -1) {
            fc = new JFileChooser("C:\\Windows");
         else {
            fc = new JFileChooser();     
         fc.setMultiSelectionEnabled(false);
         fc.setDragEnabled(false);
         //Create a new FileFilter
         ff = new INIFileFilter();
         //Add this filter to our File chooser.
         fc.addChoosableFileFilter(ff);
         fc.setFileFilter(ff);
         //Ask the user to locate it.
         do {
            dialogReturnVal = fc.showOpenDialog(mainFrame);
            if (dialogReturnVal == JFileChooser.APPROVE_OPTION) {
               nameChosen = fc.getSelectedFile().getAbsolutePath();
               if(nameChosen.toLowerCase().endsWith(INIFileFilter.FILE_TYPE)) { INIFile=new File(nameChosen); }
               else { INIFile = new File(nameChosen+INIFileFilter.FILE_TYPE); }
               if (!INIFile.exists()) {
                  continue; //If the name specified does not exist, ask again.
               else { break; }
            else { //User clicked cancel in the open dialog.
               //Ignore what we've done so far.
               return(IMPORT_ABORTED);
         } while(true); //Keep asking until cancelled or a valid file is specified.
         //Determine how many lines will be parsed.
         try {
           //Open the INI for counting
           inFileStream = new BufferedReader(new InputStreamReader(new FileInputStream(INIFile)));
           while ((inFileStream.readLine()) != null) {
               totalLines++;
           //Close the INI file.
           inFileStream.close();
         } catch (IOException ex) { return(IMPORT_FAILED); }
         //Make a progress monitor that will show progress while importing.
         progressMonitor = new ProgressMonitor(mainFrame, "Importing file","", 0, totalLines);
         progressMonitor.setProgress(0);
         progressMonitor.setMillisToPopup(100);
         progressMonitor.setMillisToDecideToPopup(1);
         //Make our DatabaseHandler to insert results to the database.
         dbh = new DatabaseHandler();
         //Open the database connection.
         do {
           try {
              openDBResult = dbh.openDBConnection(currentDB, dbLogin, dbPassword);
           } catch(JDBCException ex) { return(IMPORT_JDBC_ERROR); } //OUCH! can't write anything.
             catch(SQLException ex) {
                 openDBResult = DatabaseHandler.OPNCN_FAILED;
                 //Can not open the database. Is it password protected?
                 hasPassword = JOptionPane.showConfirmDialog(mainFrame, "Could not open the database. "+
                                                "The password is wrong or you have not specified it.\n"+
                           "Do you want to enter one now?", "New password?", JOptionPane.YES_NO_OPTION);
                if (hasPassword == MMCDCatalog.DLG_OPTN_YES) {
                   dbPassword = JOptionPane.showInputDialog(mainFrame, "Please enter your "+
                                                              "password for the DataBase:");
                    dbLogin = dbPassword; //For MSAccess, login == password                                                    
                //If the password wasn't the problem, then we can't help it.
                else { return(IMPORT_FAILED); }
         } while(openDBResult != DatabaseHandler.OPNCN_OK); //If it is OK, no exception thrown.
         //Import the ini file
         try {
            //Open the INI file for parsing.
            inFileStream = new BufferedReader(new InputStreamReader(new FileInputStream(INIFile)));
            //Read and parse the INI file. Save entries once parsed.
            while ((oneLine = inFileStream.readLine()) != null) {
               parseLine(oneLine);
               linesParsed++;
               progressMonitor.setNote("Entries imported so far: "+entriesImported);
               progressMonitor.setProgress(linesParsed);
               if ((progressMonitor.isCanceled()) || (linesParsed == progressMonitor.getMaximum())) {
                  progressMonitor.close();
                  break;
            //Close the INI file.
            inFileStream.close();
         } catch (IOException ex) {
              //Make absolutely sure the progressMonitor has disappeared
                progressMonitor.close();
                if (dbh.closeDBConnection() != DatabaseHandler.CLSCN_OK) {
                 JOptionPane.showMessageDialog(mainFrame, "Error while reading the INI file.\n"+
                    "Error while attempting to close the database", "Error", JOptionPane.INFORMATION_MESSAGE);
              else {
                 JOptionPane.showMessageDialog(mainFrame, "Error while reading the INI file.",
                                                    "Error", JOptionPane.INFORMATION_MESSAGE);     
                return(IMPORT_FAILED);
         //Make absolutely sure the progressMonitor has disappeared
         progressMonitor.close();
         //Close the database connection
         if (dbh.closeDBConnection() != DatabaseHandler.CLSCN_OK) {
            JOptionPane.showMessageDialog(mainFrame, "Error while closing the database after import.",
                                          "Error", JOptionPane.INFORMATION_MESSAGE);
         //Did the user cancel?
         if (totalLines != linesParsed) {
            return(IMPORT_ABORTED);     
         //Success!
         //Everything ok. Return the number of entries imported.
         return(entriesImported);
      }

  • File.delete() not working properly

    Hi Forum!!
    I am trying with the below code :
    File file = new file("path");
    try{
    if(file.exists())
    System.+gc+();
    file.delete();
    System.+out+.println("Control in delete trx file after deletion"+ file.exists());
    }catch(SecurityException se){
    String msg= "Delete trx file if 3gttz file created : IO Problems";
    Log.+error+(msg, se);
    }file.exists() returns false But I when I check file, it still exhists with content 0 bytes .
    Is there a way to remove the entire file from the directory rather than deleting only the
    contents ? Need not to tell I did my initial search to solve the problem.
    Thanks
    Edited by: jagabandhu on Feb 10, 2009 1:09 PM

    georgemc wrote:
    PhHein wrote:
    corlettk wrote:
    We can't all be rocket surgeons, either ;-)Heart scientist is the word you're looking for.Or rockin' sturgeons. A (marginally) cooler - albeit fictional - alternative to this abominationFrom a crazy drunk:
    A "bottle in front of me" is better than a "frontal lobotomy"!
    (Sound out those two quoted strings.)

  • Okay, i have 2 bugs with maverick.  First, when I delete a file within a window, the files deletes but the preview doesn't delete until I close the window and reopen it.  Second, I work on a network of computers and the search feature is now buggy...

    Okay, i have 2 bugs with maverick.  First, when I delete a file within a window, the files deletes but the preview doesn't delete until I close the window and reopen it.  Second, I work on a network of computers and the search feature is now buggy...  When I search for a file, A) it asks me if it's a name, or it wont produce anything, and B), its slower than in prior OS versions and in some instances I have to toggle to a different directory and go back to my original directory in the search: menu bar or the search wont produce anything...  Very buggy. 

    It appears to me that network file access is buggy in Maverick.
    In my case I have a USB Drive attached to airport extreme (new model) and when I open folders on that drive they all appear empty. If I right click and I select get info after a few minutes! I get a list of the content.
    It makes impossible navigate a directory tree.
    File access has been trashed in Maverick.
    They have improved (read broken) Finder. I need to manage a way to downgrade to Lion again.

  • Java.io.File.delete worked in 1.1, 1.2, 1.3 & 1.4, but not in 5.0

    I have a logging utility I wrote originally in Java 1.0. A nightly housekeeping task runs which creates a ZIP file for the previous days log, then deletes the .log file. If I run this software with Java 5.0, the File.delete fails and the .LOG file remains on the disk. No exceptions are thrown. delete just returns false.
    Any ideas?

    to find a bug this basic! Each day I switch to a new log file, leaving the previous days file. I was never closing the old PrintStream... Jees... How embarrassing.

  • Application server-file delete

    Hi All,
    Is there any options to delete for file in directory in Application server. If there ,please send me flow or logic.

    Hi,
    For deleting a file in the application server user the syntax DELETE DATASET..
    DELETE DATASET '/tmp/test.txt'.
    IF SY-SUBRC <> 0.
      WRITE: / 'Error in deleting'.
    ELSE.
      WRITE; / 'File deleted'.
    ENDIF.
    Thanks,
    Naren

  • Logs for File Deletion?

    I have a situation where I don't want to recover a file... I want to see how it was deleted.
    Is there any way to review file deletions via Apple log files or any other method? My research so far says no... but perhaps someone is craftier than I've proven to be.

    An unfortunate circumstance to be sure. Out of curiosity is there any particular reason you can't use ClamXAV rather than NAV?
    I suppose that if NAV has a log and nothing relevant is in the log, then you're at a loss to even know if NAV is responsible for the folder's mysterious disappearance. Maybe you have technically savvy cockroaches in the building that come out at night to play? An informational age version of Archie and Mehitabel?
    This experience may be an impetus to install software that keeps track of what's installed or removed from a computer. Doesn't help much now but it would be useful in the future.
    Oh, one thing comes to mind - file recovery software:
    Data Rescue II
    File Salvage
    TechTool Pro
    Message was edited by: Kappy

  • How to make JDS confirm file deletion?

    I use the bash shell when logged in over SSH and I always set the following alias just in case I do something stupid:
    alias rm="rm -i"Is there a similar setting for JDS that I can tell it to confirm file delete whenever I try to delete a file (i.e. popup a standard "Are you sure?" dialog box)?
    Thanks!

    By default JDS file browser "deletes" files to the trash can - a la windoze Recycle bin 8-( -
    so it doesn't feel the need to double check as you can always reclaim the file from there.
    Emptying the trash includes an "are you sure" which can be configured from the folders settings pane:
    Launch->Preferences->Desktop Preferences->Folders and pick the "Behaviour" tab
    If you mean you want the double check made in a terminal or console displayed within JDS, as opposed to using the file browser, then you need to place a suitable command in the configuration for the shell you're using e.g. .profile or .cshrc etc.
    Regards,
    Paul

  • File deletion in root and subdirectories.

    Greetings,
    I have a question regarding Batch scripting. I am trying to create a system maintenancing script which removes .TMP and .BAK files from all of my drives both subdirectories and directories above. Let's say the Batch script would be placed into "Folder3"
    in the following internal drive address "C:\Folder1\Folder2\Folder3\Folder4\Folder5". And I want the batch script to remove files from folders 4 and 5 as subdirectories but also to remove files from C: Drive and folders 1, 2, and of course 3 itself
    but without removing folders. And I'd like to apply this method to all drives simultaneously without a human user personally moving the script via cut/copy and pasting from drive to drive. The other alternative which can come into consideration is to create
    a Batch File with any address location on the internal drive and when running this Batch file it'll create additional Batch Files on specified (multiple) drives at the very root of drives in the drive address of C:\ for instance, and initializes the required
    file deletion process. Some of the folders require my Administrator priviliges therefore I'd like to create a code within the script that ask for user permission and says "Yes" but without actually asking from me as the user to click "Ok"
    or "Yes" when running the script itself or to fully bypass the firewall. I have created the other part of the coding for deleting specified superfluous file types and in what way it's just the sub and above-directory part of it that gives me a pause
    to proceed. Any help is greatly welcome or pointers. If my request would seem cluttered please notify me of it and I'll try to simplify it down, although I hope I wasn't too confusing with the elaboration.
    Thank you in advance, even for the consideration.
    Kind Regards.

    @ECHO OFF
    for %%a in (C: D: E: F: G:) do call :Sub %%a
    goto :eof
    :Sub
    echo Processing %1
    del /s /q %1\*.tmp
    del /s /q %1\*.bak

  • Why file.delete() won't work?

    I looked throught the forum and I have seen that my problem isn't the most uncommon one. I'm trying to delete a file using file.delete().But it always return false. I have used the file for reading(and sometimes writing) before but I have closed the stream, I have checked that many time ;).
    This has me a little confused. The file ins't write protected either. Is there perhaps anyway to close all streams assosiated with a certain file?

         try {
                boolean success = (new File(currentFile)).delete();
                if (!success) {
                   statusLabel.setText("Error");
                readPatients();
             catch (SecurityException se) {
                System.out.print(se);
             }Should work, shouldn't it?

  • Operations on file: Deleting and get size

    Hi,
    I'm triying to delete a file. I use the following code:
    File found = new File (directoryOutputFileWriter+f);
                   boolean deleted = found.delete();But when I execute it the boolean deleted it's always false and the file is not deleted.
    Then I try to get the size of another file in this way:
    File produced = new File(directoryOutputFileWriter+file[0]);
    long size = produced.length();but I receive a null value (the file exists and its dimension is over 0 of course).
    Why?
    How can I solve?
    Thanks, bye bye.

    Hello,
    in my experience the absolute #1 source of astonishment with file operations is loose manual checking (mistyping or misreading).
    I suggest you use those traces:
    File found = new File (directoryOutputFileWriter+f);
    System.out.println("File path is"+found.getAbsolutePath());
    System.out.println("Does this file exists? "+found.exists());
    System.out.println("Is this file really a file? "+found.isFile()); // You may not be able to delete a directory on all platforms
    System.out.println("Is this file deleted now? "+found.delete());#2 is developers not reading the javadoc (that states that delete may not succeed), but I acknowledge you have read it, as you're investigating why it hasn't, and not complaining that it has.
    #3 is people overlooking OS-specific file management. E.g. Unix-Linux-Window file permissions management all may let you read a file but not delete it (with the unices having a richer set of combinations than windows). The rules for directory deletion are different between Unices and Windows. Etc...
    Edited by: jduprez on Jul 5, 2010 9:44 AM
    @Mel: I sometimes wish I was that much connected to my wife's mind ;o)
    @Joachim: nice catch! Loose manual checking indeed (both on my part and on OP's)...

  • Alternative to File.delete() and deleteOnExit()

    Is there any GOOD way to delete physical files from a Java app running under Windows besides the File object's incredibly lame and emasculated delete() and deleteOnExit() methods?
    Despite my best efforts, I have yet to find ANY circumstances under which calling File.delete() will actually delete a file under Windows XP... It's as though the mere act of a running Java application becoming AWARE that a file exists is enough to make the JVM lock the file so nothing else can touch it (including the running app itself).
    Is there perhaps some alternate JNI-based alternative that treats deletions as more than polite suggestions that a file be considered for future removal, and PERSONALLY sees to it that the underlying OS makes an immediate and determined effort to physically delete the file IMMEDIATELY?

    The File object referenced above is used to open a FileInputStream, which is subsequently closed prior to calling the File object's delete() method.
    From what I've read about this problem over the past few days, it arises because Sun didn't follow their own best practices and left releasing the file lock to the Stream's finalize() method (or otherwise left some critical prerequisite to the lock's release to a garbage collection run)... which, as we all know, is something you should never do when you're DEPENDING upon having something executed because there's NO guarantee it will run in a timely manner, or even run at all (if, say, the application throws an Exception).
    Apparently, the problem arises something like this:
    A running Java app creates a File object and does something that requires doing actual I/O upon it, like opening an input/output stream.
    The JVM asks its abstraction layer to ask Windows to open the file. A delegate is dispatched to contact win32 and request a file lock. Windows creates a file lock in the thread's name, and gives the delegate the good news.
    The running app does its stream I/O.
    The running app closes the stream, and nullifies the object's reference just to be safe.
    Unfortunately, the JVM has other plans in mind. It throws the old Stream object into the garbage collector's work heap, then forgets it ever existed without bothering to stick around and personally make sure the file lock is released RIGHT AWAY.
    The running app continues... it's done with the file and has no further use for it, so it calls the File object's delete() method as its final act before nullifying the File object itself.
    The JVM dispatches another delegate to ask Windows to delete the file. Unfortunately, windows notices that the JVM still holds a lock on the file and tartly sends it home empty-handed, with instructions to tell its parent to make up its mind what it wants to do with the file. The delegate meekly reports failure, and the message is passed back to the running app without further action.
    What SHOULD happen:
    Calling Stream.close() should cause a delegate to be IMMEDIATELY dispatched to notify Windows that the lock should be released.
    OR, if Sun doesn't want to do that for performance reasons, then the JVM should double-check to make sure that the failure wasn't its own fault -- forcing an IMMEDIATE sweep through the garbage collector to return any queued-for-release file locks (possibly after taking a side trip to verify that the file still physically exists), followed by a second deletion attempt once it's certain that windows has responded to its request to release the lock.
    Calling System.gc() before calling File.delete() seems to work for now... but it's a really bad kludge that Sun needs to address since there's technically no guarantee that the garbage collector will actually run and release the lock.
    IMHO, this is an outright shameful bug. Sun can make all the lame excuses it wants to make about enforcing platform abstraction, but the fact is... anyone who calls File.delete() after personally making sure they've cleaned up after themselves by closing their streams has every reasonable expectation that the file will, in fact, be physically deleted unless some OTHER app or thread has acquired a secondary lock in the meantime. The buck has to stop somewhere. File deletion is one of those unglamorous tasks that nobody really thinks about until it doesn't work... and when it fails, it comes as a really rude surprise. If Sun can't alter the behavior of File.delete() for legacy reasons, then they should add an alternate method, like "File.deleteNow() throws RuntimeException" that guarantees the following behavior:
    "The JVM asks the host operating system to delete the file. If the OS refuses, the JVM tries to figure out why, and whether the failure might be its own fault. If it has reason to believe it's its own fault, it will force an immediate garbage collection run to clean up any outstanding mess, then ask the host OS to delete the file again. If it succeeds, the method returns true. If it fails, a RuntimeException (or subclass that actually lets the caller figure out why it failed) gets thrown."
    The key point is that File.delete() must NEVER fail unless some OTHER app, process, or thread that's completely unrelated to the one that locked the file and now wants it deleted has acquired a lock on the file in the meantime. I think just about everyone will agree that the current behavior of File.delete() under win32 absolutely violates the implicit contract that developers reasonably expect of a function to delete a file.
    Just to give one concrete example of a scenario where File.deleteOnExit() isn't feasible... suppose you have some emergency maintenance task that needs to be launched (with manually-supplied arguments) every few months when Something Bad happens... usually at night or over a weekend. To make life easy, the emergency app is implemented as a Servlet (so the notified individual can quickly and easily fix it in 3 minutes with his PalmOS phone and browser). The problem is, deleteOnExit() won't do much good when called from a Servlet, because the JVM running Tomcat hosting the Servlet is almost guaranteed to run for months without actually exiting... and when it finally DOES exit, it probably WON'T be graceful or intentional...

  • Help with File.delete()

    Hi All!
    I am doing the following code:
    String indexPath = "Y:/var/session/ZGCoVyCCcooSl1uHRYCAWg.idx";
    File idxFile = new File(indexPath);
    if(idxFile.exists())
    System.out.println(indexPath + " exists.");
    else
    System.out.println(indexPath + " does not exist.");
    boolean idxDeleted = idxFile.delete();
    if(!idxDeleted)
    System.out.println("could not delete " + indexPath);
    if(idxFile.exists())
    System.out.println("failed to delete " + indexPath);
    When I run this code I get the following output:
    Y:/var/session/ZGCoVyCCcooSl1uHRYCAWg.idx exists.
    Which means that the file existed and the file is deleted. But, actually file is not deleted. When I try to manually delete the file, I get "sharing violation" error. I am running this code on a Windows 2000 server system and JDK1.4. I appreciate any help.
    thanks,
    Padma.

    That IS strange. I don't have a Win2K server to test on, but I know Win2K Pro (at a client's site) seems incredibly slow at a lot of things, like when working with WinExporer. Someone told me it had to do with a configuration option. Perhaps there is something in the config telling your server to defer file deletes, e.g. "lock" the (to be)deleted file so no one can access it, mark it for deletion, but defer until later during a lull when all pending deletes can be batched at once. That would explain why you can see it, but not access it, and it goes away after some time. Then again, I might be TOTALLY out in left field... :(

  • GWCheck repetitive 'CODE 93 unused blob files (deleted)

    I've run the standalone gwcheck a few times now. with 'contents+attachment file check' and Fix problems.
    I've run it on user/message.
    It seems to me that it keeps reporting the same message after every run, I get
    Correctable conditions encountered:
    CODE DESCRIPTON COUNT
    93 Unused blob files (deleted)..................583
    It keeps reporting the same count, 583 files.
    It also reports
    Uncorrectable conditions encountered:
    CODE DESCRIPTON COUNT
    50 Unused blob files (deleted)..................18
    Any idea on how to correct it?

    Originally Posted by fribert
    I've run the standalone gwcheck a few times now. with 'contents+attachment file check' and Fix problems.
    93 Unused blob files (deleted)..................583
    It keeps reporting the same count, 583 files.
    50 Unused blob files (deleted)..................18
    Any idea on how to correct it?
    In the details above it should show the folder and BLOB file(s) it wants to delete as it crawls through the message databases. You can check to see if they actually exist. IF it is not deleting them, there is usually a reason, like they are too recent to delete, they are help open, or the options actually in effect do not allow it to repair. In the beginning of the GWCHECK log, it will show the options, and the start / end time of the run.
    I'm wondering if you are seeing the same GWCHECK log over and over, so check the start / end times to ensure its not just regurgitating the same log.
    -- Bob

Maybe you are looking for