Oliver Bock <oliver-elevatesoft-news@ikucwe.com> wrote on Mon, 20 Nov 2006 10:51:04 +1100

>(I cannot get away with telling my users not to run anti-virus software,
>and since they may download my software from the Internet I cannot sit
>in front of them and reconfigure their anti-virus software. The only
>thing I could do would be to buy every anti-virus software on the market
>and put up a web site explaining how to disable it for my software.)
>
Oliver


But you can get them to install Real VNC or Remote Assistant and then you can "sit in front of them and re-configure their anti-virus software".

We are just experimenting with "Remote Assistant" www.contextsoft.com/products/remassist at the moment and it is pretty good stuff and pretty cheap too.  And of course Michael Baytalsky, the brains behind it, is a regular contributor to the elevate ngs.

Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Jeff Cook <jeffc@aspect.co.nz> wrote on Mon, 20 Nov 2006 16:06:55 +1300

>We are just experimenting with "Remote Assistant" www.contextsoft.com/products/remassist at the moment and it is pretty good stuff and pretty cheap too.  And of course Michael Baytalsky, the brains behind it, is a regular contributor to the elevate ngs.
>

... and I was going to add ....

It is really simple to incorporate in your application.  We'll send it out the "RemoteHost.exe" and preconfigured "RemoteHost.cfg" in the Utilities directory of our application and build the following code into our main form's Help menu:-
-------------------------------------
procedure TmainForm.mnuRequestRemoteAssistanceClick(Sender: TObject);
var
 sPath, s: string;
 iniRemote: TIniFile;
begin
 sPath := sStartInDir + 'Utilities\';
 iniRemote := TIniFile.Create(sPath + 'RemoteHost.cfg');
 try
   s := iniRemote.ReadString('RemoteHost', 'User', '');
   if s = '' then
   begin
     s := Common.UserName
       + ' at ' + apmDM.CompanyTableName.AsString
       + ' ph: ' + apmDM.CompanyTableDayTimePhone.AsString;
     iniRemote.WriteString('RemoteHost', 'User', s);
   end;
 finally
   iniRemote.Free;
 end;
 s := sPath + 'RemoteHost.exe';
 ShellExecute(Self.Handle, 'open', PChar(s), nil, nil, SW_SHOWNORMAL);
end;
--------------------------
.cfg looks like this:-.
--------------------------
[RemoteHost]
Address=xxxyyyzzz.dynalias.net <<<< pointing to your machine
Port=1975
--------------------------


Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Hi Jeff,

I didn't realise just how small RemoteHost is.  It would be quite
practical to include it with our application.  Of course avoiding a
problem is still better than an easier way to fix it!


  Oliver

--
Jeff Cook wrote:
> Oliver Bock <oliver-elevatesoft-news@ikucwe.com> wrote on Mon, 20 Nov 2006 10:51:04 +1100
>
>> (I cannot get away with telling my users not to run anti-virus software,
>> and since they may download my software from the Internet I cannot sit
>> in front of them and reconfigure their anti-virus software. The only
>> thing I could do would be to buy every anti-virus software on the market
>> and put up a web site explaining how to disable it for my software.)
>>
> Oliver
>
>
> But you can get them to install Real VNC or Remote Assistant and then you can "sit in front of them and re-configure their anti-virus software".
>
> We are just experimenting with "Remote Assistant" www.contextsoft.com/products/remassist at the moment and it is pretty good stuff and pretty cheap too.  And of course Michael Baytalsky, the brains behind it, is a regular contributor to the elevate ngs.

Oliver Bock <oliver-elevatesoft-news@ikucwe.com> wrote on Mon, 20 Nov 2006 15:14:31 +1100

>I didn't realise just how small RemoteHost is. It would be quite
>practical to include it with our application. Of course avoiding a
>problem is still better than an easier way to fix it!
>
Oliver


True, but also provides a great training aid and it is always easier to give support when you can see the same thing on the screen as your user! So you also use it to avoid problems of a different nature.  Likewise with madExcept bug reports - if someone sends you the report and it has the screen-shot you say "of course - now I understand your problem!"  

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

Oliver,

<< Could DBISAM keep the files open until it's done with them? >>

It would require some major reworking of code to change the way DBISAM
handles creating and then opening temporary tables since it's the same code
used for regular tables.  Needless to say, this still wouldn't solve the
issue of simply creating a table on a local drive and then trying to open it
immediately.  There is no good answer to this problem other than the AV
software to stop interfering with the proper operation of other
applications.

<< That would stop the anti-virus software opening them.  If you used
FILE_FLAG_DELETE_ON_CLOSE you'd stop the race condition where the anti-virus
software opens the file in between you closing it and deleting it. >>

We have to support Kylix/Linux also, so we made the code more generic in
this respect.

<< (I cannot get away with telling my users not to run anti-virus software,
and since they may download my software from the Internet I cannot sit in
front of them and reconfigure their anti-virus software.  The only thing I
could do would be to buy every anti-virus software on the market
and put up a web site explaining how to disable it for my software.) >>

We've hashed over this issue for over an entire year, and the problem is
that the AV software keeps getting more and more egregious in its behavior.
At first just simply disabling scanning on a particular directory would
work.  Now, with some AV software, even that doesn't turn it off completely.
It is up to the users to take this up with the AV software vendors since
nothing we're doing is out of the ordinary or unusual from any other
database engine.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> << Could DBISAM keep the files open until it's done with them? >>
>
> It would require some major reworking of code to change the way DBISAM
> handles creating and then opening temporary tables since it's the same code
> used for regular tables.  Needless to say, this still wouldn't solve the
> issue of simply creating a table on a local drive and then trying to open it
> immediately.  There is no good answer to this problem other than the AV
> software to stop interfering with the proper operation of other
> applications.

I understand your predicament.  I should not have tried to put more
pressure on you as I know you've read it all before.  I'll keep trying
to think of ElevateSoft-based solutions because I see no realistic
chance of the anti-virus software vendors all changing their spots, not
least because they're inconsiderate, unethical scum.

I guess the problem occurs because DBISAM wants an exclusive lock on the
file.  Presumably the anti-virus software opens the file shared, read-only.

I suppose that DBISAM needs an exclusive lock on table files to avoid
them being used by multiple separate applications running DBISAM.  I
don't suppose dbisam.lck could mediate this instead?

My client running Kaspersky has had the problem three times now, but
always on temporary files.  (btw I have changed file extensions.)  Why
are the temporary files being targeted more often?  Probably Kaspersky
targets newly created files for a quick scan, but scans pre-existing
files less frequently.


   Oliver

Oliver,

<< I understand your predicament.  I should not have tried to put more
pressure on you as I know you've read it all before.  I'll keep trying
to think of ElevateSoft-based solutions because I see no realistic chance of
the anti-virus software vendors all changing their spots, not least because
they're inconsiderate, unethical scum. >>

No problem.  I'm a bit religious on this topic to some degree because I
don't think most people are aware of how much interference these products
cause in relation to their perceived benefit.  To me it seems like a case of
taking a sledgehammer to the windows in the house because they got dirty.


<< I guess the problem occurs because DBISAM wants an exclusive lock on the
file.  Presumably the anti-virus software opens the file shared, read-only.
>>

That's one of the issues, yes.  However, it would also be an issue with
simply trying to delete a file immediately after it is
created/kept-open/closed also.  There are a few scenarios where the AV
software just flat out interferes with things.  The damn AV software is
written like the only thing creating/opening/closing/deleting files on the
system is a human being, and anything else is a virus or trojan.

<< I suppose that DBISAM needs an exclusive lock on table files to avoid
them being used by multiple separate applications running DBISAM.  I don't
suppose dbisam.lck could mediate this instead? >>

In ElevateDB it does, but not with DBISAM without some serious changes.

<< My client running Kaspersky has had the problem three times now, but
always on temporary files.  (btw I have changed file extensions.)  Why are
the temporary files being targeted more often?  Probably Kaspersky targets
newly created files for a quick scan, but scans pre-existing
files less frequently. >>

I would guess that this is the reason, but frankly it is very hard to figure
out what the reasoning is behind some of the behaviors in the AV software.
Like I have always stated here - AV software should focus on monitoring the
access points to the OS and leave native processes alone.  If the virus or
trojan is already on your machine in the form of a running or runnable
process, then the damage is done IMO.

--
Tim Young
Elevate Software
www.elevatesoft.com

From an earlier post...

> Also when the error happens the temp file it is trying to access is no
> where it be found. Does DBISAM create temp files in memory?

Makes me wonder if your app is creating SOME temporary tables in a folder
that you were not expecting, and that folder has not been excluded from
the virus scan.

Presumably your app contains a line to set Session.PrivateDir to a valid
fixed location?  Is there any chance that a temp table could be created by
your app before that line executes?

--Bill Sparrow--

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:DA5F577E-3702-42CB-BBB5-406FF9F6A93F@news.elevatesoft.com...
> Oliver,
>
> << I understand your predicament.  I should not have tried to put more
> pressure on you as I know you've read it all before.  I'll keep trying
> to think of ElevateSoft-based solutions because I see no realistic chance
> of the anti-virus software vendors all changing their spots, not least
> because they're inconsiderate, unethical scum. >>
>
> No problem.  I'm a bit religious on this topic to some degree because I
> don't think most people are aware of how much interference these products
> cause in relation to their perceived benefit.  To me it seems like a case
> of taking a sledgehammer to the windows in the house because they got
> dirty.

I wish someone would sue Symantec for Norton A/V and the harm it has done to
many legitimate software companies and their products.

-Johnnie

Johnnie,

<< I wish someone would sue Symantec for Norton A/V and the harm it has done
to many legitimate software companies and their products. >>

Well, hopefully with code-signing, etc. in Windows and .NET it won't be much
longer than a few years before this stuff goes the way of the dinosaur.

--
Tim Young
Elevate Software
www.elevatesoft.com