Subject | Re: [ib-support] Log entry |
---|---|
Author | Helen Borrie |
Post date | 2003-04-03T02:46:26Z |
At 01:49 PM 2/04/2003 +0000, you wrote:
My comment on this is that they haven't looked hard enough. It's an
absolutely typical log message that you get when someone is trying to log
in while a zip or other file-level copying process is going on.
Another place worth a look is where someone is using an external tool to
access and copy the database. If their security isn't good enough, it
could be happening from anywhere on their network or, worse, by a Trojan
running in an IRC channel "somewhere in the world". If they *really* can
eliminate the possibility of someone or something in their own network
misbehaving, then take it as "suspicious". If they can reproduce the
situation, get them to take a peek with netstat -an to see what is
listening, that shouldn't be. Alarmist? Nope. This is exactly what
happened to me the week before Christmas, on my NT4 SP6a server; although
the targets in this case were SQL Server databases and PerfMon logs, not *.gdb.
OTOH, it could be something much more local, like the early throes of
hard-drive death...
heLen
>Hi,Phil,
>
>Can anyone shed any light on this error in a FB1 log file?
>
>--------
>MYSERVER (Server) Sat Mar 29 14:53:48 2003
> Database: C:\PCMETR~1.GDB
> I/O error for file "C:\PCMETR~1.GDB"
> Error while trying to write to file
> The process cannot access the file because another process has
>locked a portion of the file.
>
>internal gds software consistency check (error during savepoint backout
>(290))
>----------
>
>As far as we can tell no other process (eg backup program) accesses the *.gdb
>file directly.
>
>OS is NT4 SP6a
My comment on this is that they haven't looked hard enough. It's an
absolutely typical log message that you get when someone is trying to log
in while a zip or other file-level copying process is going on.
Another place worth a look is where someone is using an external tool to
access and copy the database. If their security isn't good enough, it
could be happening from anywhere on their network or, worse, by a Trojan
running in an IRC channel "somewhere in the world". If they *really* can
eliminate the possibility of someone or something in their own network
misbehaving, then take it as "suspicious". If they can reproduce the
situation, get them to take a peek with netstat -an to see what is
listening, that shouldn't be. Alarmist? Nope. This is exactly what
happened to me the week before Christmas, on my NT4 SP6a server; although
the targets in this case were SQL Server databases and PerfMon logs, not *.gdb.
OTOH, it could be something much more local, like the early throes of
hard-drive death...
heLen