EOFError: marshal data too short -- causes?

[Terry Reedy]

On 12/29/2015 3:01 AM, Glenn Linderman wrote:

> Now the __pycache__ directory is full of .pyc and .pyo files (from the
> install?

The installer optionally runs compileall on /Lib and recursively on its 
subpackages.  The option defaults to 'yes', at least for 'install for 
everyone', as writing files within the default Program Files location 
requires Admin permission.

On April 19th? (the date on most of the files).  But:
>
> areliabl at areliabledomain.com [~/py34/lib/python3.4/__pycache__]# ll dis*
> -rw-r--r-- 1 areliabl areliabl 14588 Dec 29 00:27 dis.cpython-34.pyc
> -rw-r--r-- 1 areliabl areliabl  8192 Dec 28 19:16 dis.cpython-34.pyc-xxx
> -rw-r--r-- 1 areliabl areliabl 14588 Apr 19  2015 dis.cpython-34.pyo-xxx
>
> (I renamed the existing .py* files by appending -xxx).
>
> So we can see that somehow, today at 19:16 (probably UTC) the dis.*.pyc
> file got chopped to 8192 bytes. That's a suspicious number, being a
> power of 2... but... I haven't updated Python since originally
> installing it on the web server, on April 19th.  So why would _that_
> .pyc file have today's date? Because of UTC, the replacement has
> tomorrow's date :)  But it seems like it should have had Apr 19 2015
> like all the rest.

I updated to 2.7.11, 3.4.4, and 3.5.1 a couple of weeks ago, so the 
timestamps are all fresh.  So I don't know what happened with 3.4.3 
timestamps from last April and whether Windows itself touches the files. 
  I just tried importing a few and Python did not.

> And isn't it rather suspicious that of the ones that are rebuilt, that
> all of them have exactly the same timestamp, rather than being sprinkled
> around with different dates?  Well, the two from Dec 15 have the same
> time, and all the ones from today have the same time. But that doesn't
> seem like some sort of "random error or access conflict accessing file
> causing it to be rebuilt"....
>
> Should I accuse my web host of playing with these files?  Are they
> backing up/restoring?  Are they simply touching the files? Is their
> infrastructure flaky such that whole groups of files get deleted now and
> then (and either rebuilt or restored with a different date)?

You could ask, without 'accusing'.  Or you could re-run compileall 
yourself.  Or you could upgrade to 3.4.4 (I recommend this) and let the 
installer do so, or not.

-- 
Terry Jan Reedy