Re: st: Slowing Stata down

[Alan Riley <ariley@stata.com>]

Laura Gibbons (gibbonsl@u.washington.edu) is encountering an error
that she believes is due to her computer processing through files too
quickly:

> My Dell PC computer has timing issues such that when Stata's accessing a 
> file on disc, Stata can occasionally go too fast, at least compared to my 
> computer, generating error messages about files being "read only".  In my 
> own code, if I have the program "sleep" for a few msec before accessing a 
> file, I can get around this.
> 
> But is there anything I can do to slow down internal Stata code?  I'm 
> trying to MI reshape a data set, and I get error messages during the 
> "assembling results" stage about files being "read only" which I know are 
> indications of the same problem.  [My computer at home, while generally 
> running faster, does not have this problem, either in my other code or 
> within MI reshape.]

We have seen a problem like this before in a few cases, and it has been
due to an unfortunate "feature" of Microsoft Windows (we might call it
a bug, but they consider it to be a feature) interacting with a virus
scanner.

It may take a few emails to determine the exact nature of the problem
and find a solution particular to Laura's case, so she should email
tech_support@stata.com and we will work with her to work around the
Windows "feature".

For those interested, here is what is happening:

   Stata creates a file, perhaps a temporary file

   The computer has a virus scanner on it which is set to scan every
   newly-created file.  Windows alerts the virus scanner of the newly-
   created file, and the virus scanner prepares to scan it.

   Stata no longer needs the file and deletes it.

   Windows tells Stata that the file has been successfully deleted.
   However, this isn't really true, because by now the virus scanner has
   opened it and is checking it out and so the file isn't quite
   deleted yet.

   Stata attempts to create another file with the same name.  Remember,
   Windows has already told Stata that the original file was
   successfully deleted, so Stata has every right to assume it can
   re-use the same name.

   Windows now realizes that the file wasn't really deleted the first
   time after all, and tells Stata that the file is in use by another
   process (the virus scanner) and can not be opened for writing.

   Stata must now stop execution with an error, as it can't create
   a file which it should be able to create.

We have had similar situations reported to us a few times, and we are
able to work with users to find workarounds.  The workarounds may
vary based on the particular virus scanner being used, the directory
in which temporary files are being saved, and the speed of the computer
and its hard drive.

In short, if the virus scanner can be told not to automatically scan
files created by Stata, or can be told not to automatically scan a
particular directory, the problem can be resolved.  If this is not
possible, we have some undocumented settings we can advise users to
tweak to help Stata deal with this "feature" in Windows.  As I said
above, Laura should contact Technical Services at tech_support@stata.com
and they will work with her to find the right workaround for her
system.


--Alan
(ariley@stata.com)
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/