Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. CFile::Remove fails [Resolved]

CFile::Remove fails [Resolved]

Scheduled Pinned Locked Moved C / C++ / MFC
questionannouncement
12 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Mike Osbahr

    Have had an app running for years and now suddenly it is unable to delete files. It is processing the data in the files. The only step it seems unable to complete now is the file deletion. I have checked the directory permissions and even recreated the directory. Has there been any recent Windows update that would make a call to CFile::Remove fail? Any other ideas what might be going on?

    Thanx, >>>-----> MikeO

    modified on Tuesday, May 25, 2010 1:48 PM

    D Offline
    D Offline
    David Crow
    wrote on last edited by
    #3

    Mike Osbahr wrote:

    Any other ideas what might be going on?

    Since CFile::Remove() is just a thin wrapper around DeleteFile(), why not call DeleteFile() directly? If it fails, call GetLastError() to find out why? This is what Remove() is doing when it throws an exception.

    "One man's wage rise is another man's price increase." - Harold Wilson

    "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

    "Man who follows car will be exhausted." - Confucius

    1 Reply Last reply
    0
    • J jeron1

      Is it throwing an exception? If so which one?

      M Offline
      M Offline
      Mike Osbahr
      wrote on last edited by
      #4

      No exception is being thrown. The program reads the contents of the file into memory, deletes the file, and then processes the data. If an exception were being thrown the data would not be processed. I can clearly see in the database though that it is. The program has been running correctly about five years now. I am hoping somebody has an idea what I can check without having to modify the code.

      Thanx, >>>-----> MikeO

      J D 2 Replies Last reply
      0
      • M Mike Osbahr

        No exception is being thrown. The program reads the contents of the file into memory, deletes the file, and then processes the data. If an exception were being thrown the data would not be processed. I can clearly see in the database though that it is. The program has been running correctly about five years now. I am hoping somebody has an idea what I can check without having to modify the code.

        Thanx, >>>-----> MikeO

        J Offline
        J Offline
        jeron1
        wrote on last edited by
        #5

        So you've got the call in a TRY/CATCH block?

        M 1 Reply Last reply
        0
        • M Mike Osbahr

          No exception is being thrown. The program reads the contents of the file into memory, deletes the file, and then processes the data. If an exception were being thrown the data would not be processed. I can clearly see in the database though that it is. The program has been running correctly about five years now. I am hoping somebody has an idea what I can check without having to modify the code.

          Thanx, >>>-----> MikeO

          D Offline
          D Offline
          David Crow
          wrote on last edited by
          #6

          Mike Osbahr wrote:

          ...deletes the file...

          So then what's the problem? :confused:

          "One man's wage rise is another man's price increase." - Harold Wilson

          "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

          "Man who follows car will be exhausted." - Confucius

          M 1 Reply Last reply
          0
          • J jeron1

            So you've got the call in a TRY/CATCH block?

            M Offline
            M Offline
            Mike Osbahr
            wrote on last edited by
            #7

            The call is in a try/catch block. An exception should also write a message to the program log. The last entry in the log is "Program started".

            Thanx, >>>-----> MikeO

            1 Reply Last reply
            0
            • D David Crow

              Mike Osbahr wrote:

              ...deletes the file...

              So then what's the problem? :confused:

              "One man's wage rise is another man's price increase." - Harold Wilson

              "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

              "Man who follows car will be exhausted." - Confucius

              M Offline
              M Offline
              Mike Osbahr
              wrote on last edited by
              #8

              I was explaining how I know that no exception is being thrown. If CFile::Remove were throwing an exception the data would not be processed. The data is being processed but the files are not being removed. This causes the file processing loop to take longer each time and eventually the program fails. I'm looking for clues why CFile::Remove might not be working and not throwing an exception. The program has been working for five years. This is why I asked about Windows updates.

              Thanx, >>>-----> MikeO

              D 1 Reply Last reply
              0
              • M Mike Osbahr

                I was explaining how I know that no exception is being thrown. If CFile::Remove were throwing an exception the data would not be processed. The data is being processed but the files are not being removed. This causes the file processing loop to take longer each time and eventually the program fails. I'm looking for clues why CFile::Remove might not be working and not throwing an exception. The program has been working for five years. This is why I asked about Windows updates.

                Thanx, >>>-----> MikeO

                D Offline
                D Offline
                David Crow
                wrote on last edited by
                #9

                Mike Osbahr wrote:

                If CFile::Remove were throwing an exception the data would not be processed.

                This implies that you are removing the file before processing it, correct?

                Mike Osbahr wrote:

                I'm looking for clues why CFile::Remove might not be working...

                See here.

                "One man's wage rise is another man's price increase." - Harold Wilson

                "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                "Man who follows car will be exhausted." - Confucius

                M 1 Reply Last reply
                0
                • D David Crow

                  Mike Osbahr wrote:

                  If CFile::Remove were throwing an exception the data would not be processed.

                  This implies that you are removing the file before processing it, correct?

                  Mike Osbahr wrote:

                  I'm looking for clues why CFile::Remove might not be working...

                  See here.

                  "One man's wage rise is another man's price increase." - Harold Wilson

                  "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

                  "Man who follows car will be exhausted." - Confucius

                  M Offline
                  M Offline
                  Mike Osbahr
                  wrote on last edited by
                  #10

                  Perhaps you should read my posts. The data in the file is read into memory before I attempt to delete the file. I am trying to get help diagnosing why a long running program would fail without modifying the code. Since the read/delete/process occur in that order within the try/catch and the data is being processed, I know that CFile::Remove is not throwing an exception. Is there an error condition of DeleteFile() for which CFile::Remove would not throw an exception?

                  Thanx, >>>-----> MikeO

                  1 Reply Last reply
                  0
                  • M Mike Osbahr

                    Have had an app running for years and now suddenly it is unable to delete files. It is processing the data in the files. The only step it seems unable to complete now is the file deletion. I have checked the directory permissions and even recreated the directory. Has there been any recent Windows update that would make a call to CFile::Remove fail? Any other ideas what might be going on?

                    Thanx, >>>-----> MikeO

                    modified on Tuesday, May 25, 2010 1:48 PM

                    L Offline
                    L Offline
                    Luc Pattyn
                    wrote on last edited by
                    #11

                    Here is an hypothesis. It may seem far fetched, it has been proven correct many times already. A file gets created. By your app or another one, not really relevant. Pretty soon (very relevant) your app wants to read that file, no problem; wants to modify or delete that file, big problem. What happens is this: something is also interested in your fresh file, opens it with read intentions, but doing so also locks it for writing and deleting. Who does this? Any piece of code that wants to help you: an anti-virus package; an automatic indexer; Google Desktop; you name it. Remedy 1: wait 1 minute. Literally. Let the helpers do their work, then remove the file. Remedy 2: use a special folder, and put it on the exceptions list of the helper, if you can identify it. Why the sudden change? did you add such helper? did one of them become slower? did the load of your system increase recently, making everything run a bit slower? FYI: Windows Explorer is well aware of this phenomenon; if you give it a delete command, which fails, it will not tell you immediately; instead it will retry 5 times at 1 second intervals, and only if that still fails, it will tell you so. (And you can find a patch to modify that "5" in the registry, Google will provide the details). :)

                    Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


                    I only read formatted code with indentation, so please use PRE tags for code snippets.


                    I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).


                    M 1 Reply Last reply
                    0
                    • L Luc Pattyn

                      Here is an hypothesis. It may seem far fetched, it has been proven correct many times already. A file gets created. By your app or another one, not really relevant. Pretty soon (very relevant) your app wants to read that file, no problem; wants to modify or delete that file, big problem. What happens is this: something is also interested in your fresh file, opens it with read intentions, but doing so also locks it for writing and deleting. Who does this? Any piece of code that wants to help you: an anti-virus package; an automatic indexer; Google Desktop; you name it. Remedy 1: wait 1 minute. Literally. Let the helpers do their work, then remove the file. Remedy 2: use a special folder, and put it on the exceptions list of the helper, if you can identify it. Why the sudden change? did you add such helper? did one of them become slower? did the load of your system increase recently, making everything run a bit slower? FYI: Windows Explorer is well aware of this phenomenon; if you give it a delete command, which fails, it will not tell you immediately; instead it will retry 5 times at 1 second intervals, and only if that still fails, it will tell you so. (And you can find a patch to modify that "5" in the registry, Google will provide the details). :)

                      Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]


                      I only read formatted code with indentation, so please use PRE tags for code snippets.


                      I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).


                      M Offline
                      M Offline
                      Mike Osbahr
                      wrote on last edited by
                      #12

                      Thanks for the helpful suggestions. It turns out my observations were flawed. The CFile::Remove is working correctly. The data processing has slowed to a crawl and it appeared that the files accumulating was the cause. Instead it is the result. Have posted a query in the Database forum now. Thanks again.

                      Thanx, >>>-----> MikeO

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups