On Thu, Jan 11, 2007 at 10:39:47PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> 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