Talk:Observer effect (information technology)

The statement cited as "Dubious" is, in fact, correct. Text files are often opened in a text editor to view. And often, the editor will keep the file open during editing, denying write access to other processes. If the process that is generating the log finds it cannot write to the log file, it may dump the message it intended to write (producing a misleading log) or sometimes just abort the whole process.

This only would apply to a editor that acquires a lock on the file and does not release it. The only other scenario where this would seem valid is if the program writes to the log file with non-blocking IO, in this case the write will fail if another process holds a lock. I am not the one who tagged the statement, but the necessary circumstances are fairly dubious. Unless you can cite a source, then this is original research.--217.84.58.104 (talk) 13:37, 28 December 2011 (UTC)

Agreed. Even if it can be argued that the statement is "correct" (still a dubious assertion, I'd say, since at most it's "correct" only for a very narrow set of circumstances), the claim needs to be sourced and cited, not simply explained. WP:NOR. FeRD_NYC (talk) 18:38, 9 August 2012 (UTC)

I'd like to suggest that, if it is retained, a better flagging than "dubious" ( Synonym:doubtful) be used. It is likely ( hopeful) that "an IO error" would, if not cause the process to stop, would surely effect the target process. Even if opened with a context editor, and not locking the log, neglecting to specify readonly would most likely cause the editor to create a work copy of the log using (and perhaps exhausting ) space. And woe be the user that routinely closes and saves files which would surely effect the log even if only adding a EOF marker as has been know to happen. A better method to view log files which are in progress on unix like systems is to use the tail command with the -f option (http://en.wikipedia.org/wiki/Tail_(Unix)#File_monitoring). DGerman (talk) 17:13, 23 April 2013 (UTC)

OP is correct as long as the "could"s remain in the statement-in-question ("the act of viewing the file while the process is running could cause an I/O error in the process, which could, in turn, cause it to stop"). Whether this happens often is the apparent topic of discussion here--not whether it does occur. Of course the actual frequency of such an event will depend on many things, including the editor selected by the user. Some editors (for ex: Notepad++) employ methods which virtually eliminate such issues but I say virtually because software cannot be proven and, thus, the word "could" does seem appropriate here. I do suggest replacing "which could, in turn," with "which may or may not".