On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > On Thu, Jan 11, 2007 at 03:14:37PM -0500, Tom Lane wrote: > >> ... And anyway there should never > >> *be* a real permissions problem; if there is then the user's been poking > >> under the hood sufficient to void the warranty anyway ;-) > > > Or some other "helpful" process such as a virus scanner has been poking > > under the hood for you... :( > > One point worth making is that I'm not really convinced anymore that > we have proof that antivirus code has been creating any such problems.
We do. I have positive proof of this being caused by AV software. I don't know that it has been the problem in *all cases*, certainly, but I've had kernel stacktraces pointing into AV filter drivers more than once. > We have several anecdotal cases where someone reported erratic > "permission denied" problems on Windows, and we suggested getting rid > of any AV code, and it seemed to fix their problem --- but how long did > they test? This problem is inherently very timing-sensitive, and so the > fact that you don't see it for a little while is hardly proof that it's > gone. See the report that started this thread for examples of apparent > correlations that are really quite spurious, like whether the test case > is being driven locally or not. It could easy be that every report > we've heard really traces to the not-yet-deleted-file problem. No, not all of them. But certainly a fair share of them can have been. > So basically what we'd have is that if you manually remove permissions > on a database file or directory you'd be risking data loss; but heck, > if you manually move, rename, delete such a file you're risking > (guaranteeing) data loss. That was the point I was trying tom ake erarlier :-) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
