home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Best of Select: Games 9
/
CD_1.iso
/
viruskil
/
tbav653
/
tbav.faq
< prev
next >
Wrap
Text File
|
1996-01-30
|
10KB
|
191 lines
This is a list with Frequently Asked Questions.
If you have a question about our product, or want to know why our product
differs from some competitive products, please check out the questions
below.
Design philosophy
-----------------
Why does TbSetup create an Anti-Vir.Dat file in every directory,
instead of generating just ONE reference file for the entire system?
1) It is more intuitive. For a user it is much easier to see
whether a directory is already processed by the checksummer or
not. You can see in one glance what the last time was you
modified the Anti-Vir.Dat file, and whether this matches with
the most recent timestamp of the executable files.
2) Maintenance. If you delete an entire directory, the checksum
base will be gone too. Automatically! With a single file
approach, you will have to run an update utility or to accept
that the database file will continue to grow for ever. The same
applies if you move a directory to another disk or
subdirectory: don't worry about the checksum files. They will
travel automatically wherever the executable files go!
3) Security. If a company decides to introduce a new software
product, they can make a backup of the diskette, scan it for
viruses, and put the checksum file on the diskette, and
multiply it and distribute it within the company. Now, whoever
gets this diskette, the checksum file will already be there.
The user won't have to bother with it himself. The new checksum
file with not interfere with the already existing ones.
4) Networks. In a LAN, different users may have access to a
directory via another path. One user may see the directory
F:\JOHN, while someone with more access rights may refer to the
same directory as G:\USERS\JOHN. With a single database
approach, you will have to create a separate database for every
user. With the checksum-file-per-directory approach, the
supervisor just creates ONE checksum base per directory, and no
matter the access rights or mappings of a specific user, if he
has access to that directory, he automatically has access to
the checksum file. So, if the supervisor updates a product on
the network, he just creates a new checksum file for that
directory, and EVERY user on the network immediately has the
correct checksum information.
Why does TbScanX not scan a file if I rename it, or when I move it to
another directory?
If you rename an executable file to another executable file, you
actually do not introduce a new file on your system. The file
was originally already there, and should have been checked by
TbScanX already when the file was introduced on your system.
If you rename a non-executable file to an executable file, you
actually introduce a new executable file on the system. This
quite unusual way to introduce a new executable file on the
system is detected by TbFile (attempt to rename a non-executable
file to an executable file).
If you move a file to another directory, using the 'move'
command, the file doesn't get actually copied when the
destination drive is the same as the original drive. What
happens is that the file gets 'renamed' to a different
directory, i.e. the file remains physically where it is, but
just the name reference is moved from one directory to the
other. TbScanX does not scan the file in this case, because the
file was already there, and has been checked when it got
introduced to your system, and doesn't need to be checked again
just because it is moved to another directory.
Why does TbScanX, unlike some other products, not scan a bootsector if
you press Ctrl-Alt-Del?
First of all, TbScanX scans a bootsector immediately if you try
to access a diskette. Most people insert a diskette because
they need a file from it, or want to copy something on it, or
just look into the directory. TbScanX will then check the
bootsector, long time before you press Ctrl-Alt-Del. So there
is not much need for TbScanX to check it when you reboot, the
job has already been done.
A second reason is that it can be dangerous to scan a diskette
while trying to reboot. You usually don't reboot just for fun!
In many cases, you reboot because the system became instable,
or because a program instructed you to reboot the system, after
it changed some vital information on the harddisk. If the
system became instable, you can damage data by accessing a
disk, and it is quite questionable anyway whether an instable
system is still able to perform a reliable disk scan. If a
program asks you to reboot, the reboot is often necessary
because the system is not aware of some changes in the
configuration, and it is dangerous to continue accessing the
disks, without - for example - the appropriate drivers.
A third reason is that it could cause people to believe that
rebooting with a diskette inserted into the drive is OK,
because the diskette will be scanned anyway. Unfortunately,
checking a diskette can only be done before a SOFT boot, and
not when you hit the reset button. It is only a partial
solution. For many people, the difference between a hard and a
soft boot is not clear, and they will just assume that rebooting
with a diskette inserted is now always safe.
So, it is dangerous, unreliable, confusing, and unnecessary in
most cases. Therefor we decided not to scan a diskette after
pressing Ctrl-Alt-Del.
Why does TbClean not clean ALL files at once?
Let's look what happens if your system is infected by a virus,
and you run an 'automatic' cleaner on it. With one and the same
virus, every executable file will be in one of the following
states after the cleaning is terminated:
1) Files that have not been affected by the virus at all.
2) Files which were infected but have been successfully cleaned.
3) Files that have been damaged (not infected!) by the virus and
can not be 'cleaned' because they have been deleted or are
overwritten.
4) Files from which the cleaner says that they have been
successfully cleaned but still don't work anymore (because of
copy protections or various other reasons).
5) Files from which the cleaner says that it failed to clean and
thus are still infected and need replacement.
Now, are you going to sort things out after the cleaner is done?
A much better approach is to work through the files on a one by
one approach. Clean one file, judge the result, test the file,
and proceed with the next one. Tedious? Yes, an even better
approach is to take that backup tape, and restore all executable
files.
Remember, viruses are not written to be bug free, and to be
compatible with all the complex configurations we are using
these days. No cleaner can repair the files incorrectly infected
by a buggy virus. Automatic cleaning is an illusion. If you
really insist on using a cleaner, you have the best chances if
you work through your files one by one.
Remember also that even viruses that are known not to damage
data still very often damage data because of interference with
disk caches, Windows, or other system software for which the
virus was not written for or properly tested against.
Network related questions
-------------------------
We have TBAV installed on a server, and we use TbScan with option