[RFC][PATCH] Change to buffer lookup for given temporary files

[Stephan Witt]

> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri <forenr at lyx.org>:
> 
> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote:
>> On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote:
>>> 
>>> Because I’m unable to test it with other PDF viewers with SyncTeX
>>> support and/or to test it on Linux and Windows I post the patch
>>> and it would be nice if you can test if it breaks something used
>>> to work.
>> 
>> It works for me on linux and cygwin, but does not on native windows.
>> Inserting some debug statements just before file_name and realtmp are
>> compared produces the following (I use C:/cygwin/tmp as the tempdir):
>> 
>> file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX
>> realtmp:   C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun
>> 
>> Seemingly, the real path of file_name is returned in the short form, while
>> that of realtmp is not. I don't know why.
> 
> Replacing the following two lines:
> 
> 	file_name = os::internal_path(trim(argument.substr(0, i)));
> 	file_name = FileName(file_name).realPath();
> 
> with
> 	file_name = os::internal_path(FileName(trim(argument.substr(0, i))).realPath());
> 
> it works also on native windows.

So, with this modification the patch would be acceptable?

I’ve attached it with your modification.

> Apparently, the only purpose of
> internal_path() on windows is returning the long form of the path
> (other than converting backslashes into slashes).

Yes, indeed. The implementation of internal_path() on windows uses the
GetLongPathNameW() function.

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getlongpathnamew

> Still, why realPath() returns a short path name in one case and not in the
> other case remains a mystery.

A lookup of the implementation of it in os_win32.cpp shows the beauty
of the Windows APIs. =8(

What I wonder: there are the Qt elements used. Why don’t we rely
on the services of QFileInfo class? E.g. canonicalFilePath() and
friends? Are there historical reasons only?

Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: goToFileRow-6.patch
Type: application/octet-stream
Size: 3843 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200219/98f251af/attachment-0001.obj>