[texhax] adobe 10

Reinhard Kotucha reinhard.kotucha at web.de
Sun May 29 01:26:57 CEST 2011


On 2011-05-28 at 19:38:05 +0200, Philipp Stephani wrote:

 > It is not necessary to lock open files on Windows, and race
 > conditions can always occur when write access to a shared resource
 > is not protected.

You mean that if AR has a file opened and you run TeX in order to
replace this file, AR sees the new file then?  Then it would crash, of
course. 
 
 > >  AR doesn't lock files on Unix.  You can have a file opened in AR
 > > while TeX is creating a new one.  AR displays the old one until
 > > you explictly reload the file.  Applications don't have to be
 > > prepared for that.
 > 
 > It has to be prepared not to read from the file while it's being
 > written.

Why?  As I said before, a file exists even after it has been deleted.
It exists until the last process accessing it dies.  AR can read from
an already opened file whenever it wants, regardless of whether TeX
created a new, incompatible, version of a file with the same name.
There are actually two distinct files, though only one of them has a
name (a directory entry).

If you want AR to display the newly created file, you have to close
the old file (which still exists) *explicitly* and open the file again.
There is absolutely nothing a programmer has to take care about.

For instance, when I update the C runtime library, all processes
started before the update are still using the old version, all
processes started after the update are using the new version.
Similarly, if I update Apache while it's running, the update has no
effect until I explicitly re-start Apache again.

I hope this makes things a bit clearer.

 > > Regarding Windows: If you think that Adobe is the culprit, then
 > > please tell them what they are doing wrong.
 > 
 > They are opening the file without sharing enabled. 

What does "without sharing enabled" mean technically?

 > I don't know why they are doing that, but this article indicates
 > that locking was not present in early versions of AR, and therefore
 > it is probably intentional:
 > http://www.planetpdf.com/forumarchive/134906.asp

I suppose that under Windows, if TeX creates a newer version of the
file, the old one is not preserved and AR sees the new one while it
still has parts of the old version in memory.  This can't work and AR
will crash then, of course.  In this case it's indeed best to lock the
file.

I could imagine workarounds, but they are quite painful to implement
and if the old and new version of a PDF file don't exist both at the
same time, AR has to be frozen completely while TeX is running, which
certainly confuses users.

Unless you can confirm that everything works properly if only the
locks are disabled, then I have to assume that Adobe does exactly the
right thing on Windows and any inconveniences are caused by Windows,
as usual.

 > >  I assume that they are able to open a file properly, they do
 > > this on other systems too and it works perfectly there.
 > 
 > No, both the interface and the semantics are quite different. On
 > Windows, file locks are acquired by the CreateFile function; on OS
 > X, you can use certain flags for the open function; and on Linux,
 > you have to use the flock/lockf/fnctl functions.  This article
 > seems to indicate that file locks don't actually work on Unix
 > systems, so perhaps that's the reason why Adobe chose not to lock
 > the files there: http://apenwarr.ca/log/?m=201012#13

No.  Adobe doesn't lock files on Linux because

  a) it's not necessary, what should it be good for?

  b) it's horribly annoying.  Why should one want to cripple AR on
     Unix deliberately without any good reason?  It works perfectly as
     it is.  I'm aware that Windows users can't imagine that one and
     the same program works perfectly on Unix while it's quite
     unusable under Windows.

Only Windows users are complaining about file locking.  What is the
benefit of file locks on Unix?  There is absolutely no need to make AR
on Unix as inconvenient as it is on Windows.

 > > I don't know why everybody is blaming Adobe for the file locking
 > > mess.
 > 
 > I don't know why everybody is blaming Microsoft for the file
 > locking mess, given that is is perfectly valid to open a file
 > without locking on Windows, and that it's purely the choice of the
 > application developers whether they want locking or not, and there
 > exist many applications that avoid locking open files or keeping
 > them open all the time.  

See above.  I'm not blaming Microsoft because AR locks the files.  The
question is whether programs work properly under Windows if files are
_not_ locked.  I think that you can't blame Adobe for the
inconveniences if the locks are necessary under Windows (even though
they can be turned off).

Stupid question: Does AR crash on Windows if the file is _not_ locked
and TeX creates a new one?  If yes, then Adobe's decision is correct.

 > The solution to all this (using Sumatra PDF) has already been
 > posted, so I don't see much reason to continue this thread.

It's not a solution at all, sorry.  Does Sumatra PDF support
animations, movies, JavaScript, layers, interactive 3D graphics,
attachments, and so on?  All this is already supported by pdftex since
it exists, i.e. for more than a decade.  Most PDF viewers are not even
able to display the documentation of the respective LaTeX packages
properly, hence people using crippled viewers don't even notice what
they are missing.

Sorry, but PDF is by far much more than DVI with hyperlinks.

I can only recommend to use a PDF viewer which actually supports PDF,
even if it's a bit clumsy and only free in the sense of free beer.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------


More information about the texhax mailing list