[tex-live] Testing and Upgrading on Windows
George N. White III
gnwiii at gmail.com
Wed Jun 29 13:54:02 CEST 2011
On Wed, Jun 29, 2011 at 9:47 AM, <texlive.jlists at spamgourmet.com> wrote:
> On Tue, 28 Jun 2011 22:55:12 +0200, Siep Kroonenberg <siepo at cybercomm.nl>
>>> There seems to be some race-condition. To avoid these, I think an
>>> option is
>>> to use some directory inside %TEMP% (eg. %TEMP%/texlive) as location for
>>> temporary files instead of some place within %programsdir%.
Have you ruled out a hardware or filesystem problem? A race condition may
be revealed by a badly fragmented drive or a drive that is spending a
lot of time
on excessive error recovery. Have you run chkdsk and is there ample free space
on the drive? A S.M.A.R.T. utility may show error recovery stats.
>> We are familiar with random `Permission denied' errors on Windows
>> and are still at a loss what to do about them.
>> Why do you think this might help? This is a real question, not an
>> attempt at sarcasm.
> At least on the system in question, I could discover two jobs continuously
> monitoring the file system for new files:
> 1. Windows Search (indexing service)
> 2. backup cron job
> and on most system there probably is also
> 3. virus scanner
> That said, what the installer is doing here is "uncommon": Files installed
> normally do not get accessed immediately after. - This *might* be the reason
> (one of the reasons?) here.
Have you checked the event viewer for more information? If you use iastor you
should make sure it is the current version. Are you using a usbdrive?
> While I am in favour of asking the user to disable (3) during installation
> (this request seems to be quite common, especially for installations not
> using the system build-in installer), there will still be (1), (2).
> Nonetheless, these will most likely exclude known locations for temporary
> files (as %TEMP%).
There are so many different policies in large organizations, and the trend is
to add limits to what what users can do. In particular, some site policies do
not allow a user to disable AV, and some potential users will be put
they fear hackers could insert some malware into a TL archive and rely on AV as
a layer of protection. Most AV scanners provide logs, so before recommending
disabling AV we should determine exactly what is running afoul of AV scanners
and try to work around that.
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live