Notice: On March 31, it was announced that Statalist is moving from an email list to a forum. The old list will shut down at the end of May, and its replacement, statalist.org is already up and running.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: st: Slowing Stata down
Alan Riley <email@example.com>
Re: st: Slowing Stata down
Wed, 22 Feb 2012 16:40:46 -0600
Laura Gibbons (firstname.lastname@example.org) is encountering an error
that she believes is due to her computer processing through files too
> 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
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
email@example.com and we will work with her to work around the
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
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 firstname.lastname@example.org
and they will work with her to find the right workaround for her
* For searches and help try: