[texhax] adobe 10
st_philipp at yahoo.de
Sat May 28 19:38:05 CEST 2011
Am 28.05.2011 um 18:43 schrieb Reinhard Kotucha:
> On 2011-05-28 at 15:44:39 +0200, Philipp Stephani wrote:
>>>>> if it is windows, then why doesn't it lock it for Sumatra PDF?
>>>> The Windows kernel locks opened files only if requested by the
>>>> caller (i.e. the application). Files can be opened with or without
>>>> read and/or write locking. See the documentation for the CreateFile
>>>> function for details.
>>> The question is: what happens on Windows if a file is _not_ locked and
>>> is replaced by a process (TeX) while another one (AR) is accessing it.
>>> Only removing the lock might not be sufficient, and I suppose it's not
>>> set for fun.
>> If an application doesn't lock a file for writing, then other
>> processes can open it for writing, so the application has to be
>> prepared for that. But that has nothing to do with Windows.
> Of course it has.
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.
> 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.
> 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. 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:
> 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:
> 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.
The solution to all this (using Sumatra PDF) has already been posted, so I don't see much reason to continue this thread.
More information about the texhax