•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the C++ section within the Software Development category of DaniWeb, a massive community of 426,434 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,330 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our C++ advertiser: Programming Forums
Views: 4459 | Replies: 16
![]() |
As seen in another thread, I'm working on a Log class. I'm running into an issue that if I delete the file that's being written to, the Log class doesn't detect it and continues to 'think' it's writing even though the file is gone... (Note that this is on sun solaris in case it matters)
I've tried the following to try and detect this
(assuming my ofstream is named out)
!out.is_open()
!out.good()
out.fail()
None of them seem to detect this issue. (Nor changing the permissions to non-write while the file has already been opened by the app). Note that these functions DO catch a problem with opening the file, but not when it's already opened. Any advice?
I've tried the following to try and detect this
(assuming my ofstream is named out)
!out.is_open()
!out.good()
out.fail()
None of them seem to detect this issue. (Nor changing the permissions to non-write while the file has already been opened by the app). Note that these functions DO catch a problem with opening the file, but not when it's already opened. Any advice?
•
•
•
•
Originally Posted by winbatch
As seen in another thread, I'm working on a Log class. I'm running into an issue that if I delete the file that's being written to, the Log class doesn't detect it and continues to 'think' it's writing even though the file is gone... (Note that this is on sun solaris in case it matters)
I've tried the following to try and detect this
(assuming my ofstream is named out)
!out.is_open()
!out.good()
out.fail()
None of them seem to detect this issue. (Nor changing the permissions to non-write while the file has already been opened by the app). Note that these functions DO catch a problem with opening the file, but not when it's already opened. Any advice?
Why not close the file descriptor?
Not sure I follow. I have a program that is writing/appending to a file every second (as a test). In another window/session, I'm deleting that file via the rm command in unix. I want my program to detect that it can no longer write to the file. instead, it just keeps on writing. (Though nothing is actually written as the file is gone)
•
•
•
•
Originally Posted by winbatch
Not sure I follow. I have a program that is writing/appending to a file every second (as a test). In another window/session, I'm deleting that file via the rm command in unix. I want my program to detect that it can no longer write to the file. instead, it just keeps on writing. (Though nothing is actually written as the file is gone)
So, in *nix, when you open a file descriptor, you grab a reference to that file. Thus, when you unlink(2) that file using the "rm" command, you're only dropping that reference. Because you have a stream open (and another reference), the file will not actually be removed [yet]. Once you close the stream, you will release that reference, and presumably at that point the file's reference count will then drop to 0 and be "removed".
Ah reference counting, fun for the entire family.
What you want to do is not possible in standard C++. You seem to think that a file stream knows if the external device is available if you remove it between construction and destruction of the stream. In reality, all you're doing is invoking undefined behavior by writing to a device that you've told the stream exists and will continue to exist until destruction. That's an implied contract when you open a file stream and you're not adhering to it.
My kneejerk reaction to this problem is to tell you not to delete the file until you're done with it. However, you can do a platform dependent test to see if the file exists before every operation on it. However, that's inefficient and just sweeps the dirt under the rug.
My kneejerk reaction to this problem is to tell you not to delete the file until you're done with it. However, you can do a platform dependent test to see if the file exists before every operation on it. However, that's inefficient and just sweeps the dirt under the rug.
I'm a programmer. My attitude starts with arrogance, holds steady at condescension, and ends with hostility. Get used to it.
•
•
•
•
Originally Posted by winbatch
I was only deleting it to see if my class would detect it. So what you're saying is that it can't detect the deletion, or a change in permissions, etc. What about running out of disk space?
So, if you're writing a program that's specific to a "unix" system why not use C and OS libraries?? And, like I told you, your concept and understanding of "deletion" is wrong. You can't detect deletion because nothing is BEING deleted.
>So what you're saying is that it can't detect the deletion, or a change in permissions, etc
Did I studder?
>What about running out of disk space
That will cause failbit (and possibly badbit) to be set.
>By the way, if not for detecting problems writing, what's the point of the .bad() and .fail() functions?
You're confusing errors during legitimate use with blatant and intentional breaking of the rules.
Did I studder?
•
•
•
•
Originally Posted by Narue
What you want to do is not possible in standard C++.
That will cause failbit (and possibly badbit) to be set.
>By the way, if not for detecting problems writing, what's the point of the .bad() and .fail() functions?
You're confusing errors during legitimate use with blatant and intentional breaking of the rules.
I'm a programmer. My attitude starts with arrogance, holds steady at condescension, and ends with hostility. Get used to it.
![]() |
•
•
•
•
•
•
•
•
DaniWeb C++ Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
3d apple blue screen cocoa computer crash dell development drivers email enterprise eudora firefox framework games gnu graphics ibm intel internet java linux microsoft microsystems mozilla news next open open source open-source opengl openoffice operating os penelope programming red hat rhel server software source step sun super system ubuntu vista wesnoth windows xp
- Previous Thread: help me to correct this part of my program
- Next Thread: Cubed root function?




Linear Mode