[tex-live] Testing and Upgrading on Windows

[George N. White III]

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>
> wrote:
>
>[...]
>>> 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
off because
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