windows defender issues? & other AV issues

[Richard Gaskin]

R.H. wrote:

 > I just feel that we should know what the problem is that corrupts the
 > stack when saving and the original stack filename is appended with the
 > tilde character?

Agreed.  If the engine has a problem writing stack files, that would 
prevent us from using LiveCode.

The trick now is to pin down the cause of the issue you've experienced.

Since we don't see many reports here of errant stack saves, it seems 
this will require some sleuthing to pin down the specific combination of 
factors at play.


 > Is there any way to detect and catch an error when saving?

All I/O, whether socket or disk, whether stack files or any other 
format, is ideally accompanied by error-checking, e.g.:

   save stack tStackFilePath
   if the result is not empty then
      answer "Couldn't save document ("& sysError() &")"
      exit to top
   end if

The sysError function is especially useful there, delivering the error 
number the OS provides to describe the specific reason the file could 
not be written.


 > Saving either from the IDE or saving the compiled in any case (with or
 > without corruption) takes way too long time. My tests disabling
 > Windows Defender did not change this...

How much is "too long time", and what's in the file?

The number of cards may be particularly relevant for save time, perhaps 
number of substacks if there are many.  File size when written 
successfully would be good know too.


 > And I can not ask clients to disable Windows Defender or change the
 > Defender settings anyway. I have no control over such machines and
 > it is a big company with some users using my app. They are mostly
 > illiterate even to open Windows Defender or they are not permitted
 > to change any settings.

I'm with you, very disinclined to encourage users to turn off built-in 
security features.

I haven't done more research on this in weeks, but back when I did the 
many other apps affected by this were of such a broad variety no clear 
pattern was self-evident to me which would explain how LC could be among 
them.

As time permits I may do some more reading around the web to see how 
other vendors are coping with this.


 > But generally said, I would also prefer to go with a proper
 > installation tool, read from and write to files in the AppData or
 > Documents directory....

More than OS-recommended practice, often essential.  All user data 
should be in user space.


 > A stack is just not a good database solution if data is well
 > structured and there is a lot of data.

Agreed.  If you need a DB you should use a DB, which will have its own 
binary file format(s).  (But of course then the question is which type 
of DB: relational, document store, graph, or something else?)

There are almost as many file formats as their are document-producing 
applications. No singe file format can accommodate all possible types of 
apps, so we use the format best suited for the type of app we're making.


The bad thing about file formats is that there is no one-size-fits-all 
solution, so we have to make choices about what's best for the task at hand.

The great thing about file formats is that there is no one-size-fits-all 
solution, so we get to make choices about what's best for the task at hand.

:)

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com