|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Log file accessthan a coding issue. Some years ago I wrote a simple vb monitoring tool which creates a text-based log file. It doesn't check for write-protection on the file, so if someone has the log file open in an editor when the app tries to write to it, the app falls over. Clearly I need to protect against this with an 'on error' function, but what should I do then? I can set a flag so that a message is written to the log file at the next successful access saying "log entires at [times] could not be made due to file permissions - perhaps the file was open in another application" but I could still be misled if the app fails for another reason and the last few lines of debug have not been written out due to someone having the log open. I could write to a second debug file if the app can't open the first - but then if one user leaves the first debug file open and the app starts to write to the second, another user may open the second and I'm in the same position again. Thinking about it, another option is to use privileges to ensure the log file is read-only for everyone except the user under which the app runs. What have others done in this situation...? Many thanks, Steve
Show quote
"Steve" <st***@hatchwarren.plus.com> wrote in message It seems there is more to the story than what you have told us, because whynews:9dc40547-a747-43bb-a100-376e6798436c@c29g2000hsa.googlegroups.com... > What I'm really looking for here is assistance with design, rather > than a coding issue. > > Some years ago I wrote a simple vb monitoring tool which creates a > text-based log file. It doesn't check for write-protection on the > file, so if someone has the log file open in an editor when the app > tries to write to it, the app falls over. Clearly I need to protect > against this with an 'on error' function, but what should I do then? I > can set a flag so that a message is written to the log file at the > next successful access saying "log entires at [times] could not be > made due to file permissions - perhaps the file was open in another > application" but I could still be misled if the app fails for another > reason and the last few lines of debug have not been written out due > to someone having the log open. I could write to a second debug file > if the app can't open the first - but then if one user leaves the > first debug file open and the app starts to write to the second, > another user may open the second and I'm in the same position again. > > Thinking about it, another option is to use privileges to ensure the > log file is read-only for everyone except the user under which the app > runs. > > What have others done in this situation...? > would anybody else have this "debug log file" open? Is this an actual problem, or are you just doing a "thought-experiment". Such collisions are rare in real life. <g> For debug trace statements where a developers is "debugging" a particular application you might investigate using the DebugOutputString API in conjuction with a DebugViewer. Private Declare Sub OutputDebugString Lib "kernel32" Alias "OutputDebugStringA" (ByVal lpOutputString As String) http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx In those situations were you are using a "Verbose" option - that is a running application in a production environment you can hide the log behind your own "Viewer", Or perhaps anything in between. Hi Ralph, Thanks for the quick response.
On 19 Nov, 14:07, "Ralph" <nt_consultin***@yahoo.com> wrote: There's not really any more to it. We have a 3rd-party helpdesk tool> It seems there is more to the story than what you have told us, because why > would anybody else have this "debug log file" open? Is this an actual > problem, or are you just doing a "thought-experiment". Such collisions are > rare in real life. <g> which (at least in the version we have) isn't great at reporting calls created by third parties, notifying interested parties (who don't use the helpdesk tool) when urgent calls are logged etc. My app therefore checks the tool's database every minute, and if it finds calls matching certain criteria it uses an SMTP dll to notify the relevant parties by email. It maintains a simple text-based log file which records checks made and emails sent, with a date and time stamp. I see I drifted into using the term 'debug' in my original post, which was probably misleading - I should really have called it a log file throughout. The users of the system being IT-literate, if the app seems to stop working - especially if I'm not around - they go exploring, find the log file and open it up in an editor. If the app was working until this point, it soon stops as it now fails with a file access error on the log file. > Again, apologies, it's not really debug but logging...> For debug trace statements where a developers is "debugging" a particular > application you might investigate using the DebugOutputString API in > conjuction with a DebugViewer. > Private Declare Sub OutputDebugString Lib "kernel32" > Alias "OutputDebugStringA" (ByVal lpOutputString As String)http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView... > Ideally I prefer the idea of a straightforward, text-based log file if> In those situations were you are using a "Verbose" option - that is a > running application in a production environment you can hide the log behind > your own "Viewer", > > Or perhaps anything in between possible (though I realise I may need to compromise here). Having moaned about the fact that others open the log file in an editor, it's actual quite helpful that they can investigate and resolve problems when I'm not around - as long as I can find a way for them to do that without either causing the app to fail or losing log data. Steve
Show quote
"Steve" <st***@hatchwarren.plus.com> wrote in message I think a simple version of Dave O's idea would work fine, something like this news:0d39f63a-65a8-423f-b86c-18cee8ac740e@o6g2000hsd.googlegroups.com... > > > There's not really any more to it. We have a 3rd-party helpdesk tool > which (at least in the version we have) isn't great at reporting calls > created by third parties, notifying interested parties (who don't use > the helpdesk tool) when urgent calls are logged etc. My app therefore > checks the tool's database every minute, and if it finds calls > matching certain criteria it uses an SMTP dll to notify the relevant > parties by email. It maintains a simple text-based log file which > records checks made and emails sent, with a date and time stamp. > > > The users of the system being IT-literate, if the app seems to stop > working - especially if I'm not around - they go exploring, find the > log file and open it up in an editor. If the app was working until > this point, it soon stops as it now fails with a file access error on > the log file. > done every minute: Try to open main log file for exclusive use. If main fails, open secondary log file, perhaps with a .dat extension Write the log entry to the secondary file. Close the secondary file. If main succeeds, check for a secondary log file. If secondary found then Read the secondary and write it to the main log file. Delete the secondary. Write the new log entry to the main file. Close the main file. That should let your app continue logging if someone is reading the log file, and catch up when they are done. I agree that you should continue to have an accessible log file, they can be very useful, and letting users help themselves is always a good idea.
Show quote
On 19 Nov, 15:15, "Steve Gerrard" <mynameh***@comcast.net> wrote: Hi Steve,> I think a simple version of Dave O's idea would work fine, something like this > done every minute: > > Try to open main log file for exclusive use. > If main fails, open secondary log file, perhaps with a .dat extension > Write the log entry to the secondary file. > Close the secondary file. > If main succeeds, check for a secondary log file. > If secondary found then > Read the secondary and write it to the main log file. > Delete the secondary. > Write the new log entry to the main file. > Close the main file. > > That should let your app continue logging if someone is reading the log file, > and catch up when they are done. > > I agree that you should continue to have an accessible log file, they can be > very useful, and letting users help themselves is always a good idea. Thanks - looks like that's the approach I need to adopt. Steve
Show quote
"Steve" <st***@hatchwarren.plus.com> wrote in message just a thoughtnews:0d39f63a-65a8-423f-b86c-18cee8ac740e@o6g2000hsd.googlegroups.com... > Hi Ralph, Thanks for the quick response. > > On 19 Nov, 14:07, "Ralph" <nt_consultin***@yahoo.com> wrote: > > Ideally I prefer the idea of a straightforward, text-based log file if > possible (though I realise I may need to compromise here). Having > moaned about the fact that others open the log file in an editor, it's > actual quite helpful that they can investigate and resolve problems > when I'm not around - as long as I can find a way for them to do that > without either causing the app to fail or losing log data. > > Steve can you log to a "private" version then when the user needs to review a log, a copy is made of the "private" log state at that moment...and that's the one they see? On 19 Nov, 15:17, "MP" <NoS***@Thanks.com> wrote: Unfirtunately users view the log simply by accessing it with a viewer> just a thought > can you log to a "private" version > then when the user needs to review a log, a copy is made of the "private" > log state at that moment...and that's the one they see? over the network, not via my application, so there is no way to capture the fact that they are viewing the file. Steve Something like Notepad will not keep the file open Steve. It initially reads
the entire file, closes it, and may then write it back later (or Save As elsewhere, or not write back at all) If you're worried about multiple instances of your helpdesk application writing to the log at the same time then you can change the way the file-open and the file-writes are done to ensure that it works with multiple users/processes/threads/whatever. For instance: http://groups.google.ie/group/microsoft.public.vb.com/msg/e2e67b2bdfc0ae5b Tony Proctor Show quote "Steve" <st***@hatchwarren.plus.com> wrote in message String)http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugViewnews:0d39f63a-65a8-423f-b86c-18cee8ac740e@o6g2000hsd.googlegroups.com... > Hi Ralph, Thanks for the quick response. > > On 19 Nov, 14:07, "Ralph" <nt_consultin***@yahoo.com> wrote: > > > It seems there is more to the story than what you have told us, because why > > would anybody else have this "debug log file" open? Is this an actual > > problem, or are you just doing a "thought-experiment". Such collisions are > > rare in real life. <g> > > There's not really any more to it. We have a 3rd-party helpdesk tool > which (at least in the version we have) isn't great at reporting calls > created by third parties, notifying interested parties (who don't use > the helpdesk tool) when urgent calls are logged etc. My app therefore > checks the tool's database every minute, and if it finds calls > matching certain criteria it uses an SMTP dll to notify the relevant > parties by email. It maintains a simple text-based log file which > records checks made and emails sent, with a date and time stamp. > > I see I drifted into using the term 'debug' in my original post, which > was probably misleading - I should really have called it a log file > throughout. > > The users of the system being IT-literate, if the app seems to stop > working - especially if I'm not around - they go exploring, find the > log file and open it up in an editor. If the app was working until > this point, it soon stops as it now fails with a file access error on > the log file. > > > > > For debug trace statements where a developers is "debugging" a particular > > application you might investigate using the DebugOutputString API in > > conjuction with a DebugViewer. > > Private Declare Sub OutputDebugString Lib "kernel32" > > Alias "OutputDebugStringA" (ByVal lpOutputString As .... Show quote > > Again, apologies, it's not really debug but logging... > > > > > In those situations were you are using a "Verbose" option - that is a > > running application in a production environment you can hide the log behind > > your own "Viewer", > > > > Or perhaps anything in between > > Ideally I prefer the idea of a straightforward, text-based log file if > possible (though I realise I may need to compromise here). Having > moaned about the fact that others open the log file in an editor, it's > actual quite helpful that they can investigate and resolve problems > when I'm not around - as long as I can find a way for them to do that > without either causing the app to fail or losing log data. > > Steve > On 19 Nov, 16:17, "Tony Proctor"
<tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote: > Something like Notepad will not keep the file open Steve. It initially reads Thanks for that - a brief experiment with multiple editors confirms> the entire file, closes it, and may then write it back later (or Save As > elsewhere, or not write back at all) your comments. The only one I could find which held the file open was Word, which is an unlikely (though not impossible) candidate. It did get me thinking though - perhaps the reason I see this problem so intermittently is that it only occurs while the viewer in question has the file open for reading (or writing if they choose to save it back). > If you're worried about multiple instances of your helpdesk application Thanks, but there's only a single instance of my monitoring app (and> writing to the log at the same time then you can change the way the > file-open and the file-writes are done to ensure that it works with multiple > users/processes/threads/whatever. For instance:http://groups.google.ie/group/microsoft.public.vb.com/msg/e2e67b2bdfc... that's what writes to the file, the helpdesk app itself does not). Steve I can confirm that if you use that class to write to your log file Steve,
then Notepad can still read the file, but it cannot interfere with the writes because your channel would have been opened and kept open whilst the Helpdesk app is running Tony Proctor Show quote "Steve" <st***@hatchwarren.plus.com> wrote in message instance:http://groups.google.ie/group/microsoft.public.vb.com/msg/e2e67b2bdnews:a8b0c734-d5ca-4d39-bf7a-773e53b1f12f@e25g2000prg.googlegroups.com... > On 19 Nov, 16:17, "Tony Proctor" > <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote: > > Something like Notepad will not keep the file open Steve. It initially reads > > the entire file, closes it, and may then write it back later (or Save As > > elsewhere, or not write back at all) > > Thanks for that - a brief experiment with multiple editors confirms > your comments. The only one I could find which held the file open was > Word, which is an unlikely (though not impossible) candidate. > > It did get me thinking though - perhaps the reason I see this problem > so intermittently is that it only occurs while the viewer in question > has the file open for reading (or writing if they choose to save it > back). > > > > If you're worried about multiple instances of your helpdesk application > > writing to the log at the same time then you can change the way the > > file-open and the file-writes are done to ensure that it works with multiple > > users/processes/threads/whatever. For fc... Show quote > > Thanks, but there's only a single instance of my monitoring app (and > that's what writes to the file, the helpdesk app itself does not). > > Steve "Steve" <st***@hatchwarren.plus.com> wrote in message Tell your users to stop using a program so stupid that it will lock a text news:0d39f63a-65a8-423f-b86c-18cee8ac740e@o6g2000hsd.googlegroups.com... > The users of the system being IT-literate, if the app seems to stop > working - especially if I'm not around - they go exploring, find the > log file and open it up in an editor. If the app was working until > this point, it soon stops as it now fails with a file access error on > the log file. file. I don't know of any text editors that do this by default. They're not using (stupid) Excel to do this, are they? On 19 Nov, 16:28, "Jeff Johnson" <i....@enough.spam> wrote: As noted above, not Excel but possibly its equally stupid cousin Word.> Tell your users to stop using a program so stupid that it will lock a text > file. I don't know of any text editors that do this by default. They're not > using (stupid) Excel to do this, are they? But as also noted above, I may have been on the wrong track anyway and it may be only on file reads by the editors that the locking occurs, not all the time that the editor has the file open. The solution will work the same in either case though... Steve PS At the risk of going OT, is there an elegant way to reply to multiple users in a single post when wishing to acknowledge contributions from various others, as I have over the last few posts? I'm ashamed to admit I'm posting using Google Groups (I know, I know) so if it's a feature only available in proper newsreaders I'll just shut up... "Steve" <st***@hatchwarren.plus.com> wrote in message I just usually make a single post directly below the original post (which, news:c27f804c-f5b5-4506-b62d-baa4c728627f@s8g2000prg.googlegroups.com... > PS At the risk of going OT, is there an elegant way to reply to > multiple users in a single post when wishing to acknowledge > contributions from various others, as I have over the last few posts? > I'm ashamed to admit I'm posting using Google Groups (I know, I know) > so if it's a feature only available in proper newsreaders I'll just > shut up... yes, makes it look like I'm replying to myself) and say "Thanks everybody." The newsgroup-savvy will understand. Hi
Here is one possible method: You could write to a session log then try to append it to the main log and on success delete the session log. If the append fails you leave the session log in place and attempt to append it later. You could give the session log an extension other than TXT or LOG so it can't easily be opened with Notepad. Regards Dave OF. Show quote "Steve" <st***@hatchwarren.plus.com> wrote in message news:9dc40547-a747-43bb-a100-376e6798436c@c29g2000hsa.googlegroups.com... > What I'm really looking for here is assistance with design, rather > than a coding issue. > > Some years ago I wrote a simple vb monitoring tool which creates a > text-based log file. It doesn't check for write-protection on the > file, so if someone has the log file open in an editor when the app > tries to write to it, the app falls over. Clearly I need to protect > against this with an 'on error' function, but what should I do then? I > can set a flag so that a message is written to the log file at the > next successful access saying "log entires at [times] could not be > made due to file permissions - perhaps the file was open in another > application" but I could still be misled if the app fails for another > reason and the last few lines of debug have not been written out due > to someone having the log open. I could write to a second debug file > if the app can't open the first - but then if one user leaves the > first debug file open and the app starts to write to the second, > another user may open the second and I'm in the same position again. > > Thinking about it, another option is to use privileges to ensure the > log file is read-only for everyone except the user under which the app > runs. > > What have others done in this situation...? > > Many thanks, > > Steve  |
|||||||||||||||||||||||
Other interesting topics