[tex-live] texindy problems on Win7 (UNC paths?)

Lars Madsen daleif at imf.au.dk
Wed Apr 17 15:40:17 CEST 2013


I was wondering about those drive names as well. They do not seem fixed, though, one Drive is, the X: drive, that is apparently setup for shared folders.

There may be roaming profiles involved as well (I don't use this kind of windows in my normal tests, it is just a standalone Win7).

I'm not quite sure how the files are synced onto the file server. Our users with laptopns can take their laptops home with them and work on their files 'offline', they are then synced when the attach a cable the net morning (or if they perhaps is using VPN).

The PC in question is a normal desktop computer.

Let me know it there are any direct questions that I need to ask our Windows people.




/Lars Madsen
Institut for Matematik / Department of Mathematics
Aarhus Universitet / Aarhus University
Mere info: http://au.dk/daleif@imf / More information: http://au.dk/en/daleif@imf


________________________________________
From: tex-live [tex-live-bounces at tug.org] on behalf of Siep Kroonenberg [siepo at cybercomm.nl]
Sent: 17 April 2013 15:29
To: tex-live at tug.org
Subject: Re: [tex-live] texindy problems on Win7 (UNC paths?)

On Wed, Apr 17, 2013 at 11:04:35AM +0000, Lars Madsen wrote:
> Some data:
>
> texindy -t logfile:
>
> Y:\Users\name\Documents\MATH\artikler\Bog\xxx-Fueq>texindy -t mylog.log -L English fueq_master.idx
> Opening logfile "mylog.log" (done)
> Reading indexstyle...
> Loading module "qRctlFiO10"...
> ERROR: OPEN: #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"mylog.log"> already points to file "Y:\\Users\\name\\Documents\\MATH\\artikler\\Bog\\xxx-Fueq\\qRct
> lFiO10", opening the file again for :INPUT-IMMUTABLE may produce unexpected results
> C:\texlive\2012\bin\win32\runscript.tlu:591: command failed with exit code 1:
> perl.exe c:/texlive/2012/texmf/scripts/xindy/texindy.pl -t mylog.log -L English fueq_master.idx
>
> the contents of mylog.log (without the comments at the top):
>
> ERROR: OPEN: #<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"mylog.log"> already points to file "Y:\\Users\\stetkaer\\Documents\\MATH\\artikler\\Bog\\stetkaer-Fueq\\qRctlFiO10", opening the file again for :INPUT-IMMUTABLE may produce unexpected results
>
> ------------
>
> net use :
>
>
> Y:\Users\name\Documents\MATH\artikler\Bog\xxx-Fueq>net use
> New connections will not be remembered.
>
>
> Status       Local     Remote                    Network
>
> -------------------------------------------------------------------------------
>              P:        \\ad.nfit.au.dk\nfdfs\Users\name
>                                                 Microsoft Windows Network
>              X:        \\ad.nfit.au.dk\NFDFS     Microsoft Windows Network
>              Y:        \\ad.nfit.au.dk\NFDFS     Microsoft Windows Network
>              Z:        \\ad.nfit.au.dk\NFDFS     Microsoft Windows Network
> The command completed successfully.

Thanks.

However, the screenshot references a drive letter V:, which does not
show up above.

Was this a special case? Or maybe something or somebody created a
mapping for the Documents folder on the fly? (A very wild guess)

Another oddity: X:, Y: and Z: appear to be three mappings to one and
the same share. AFAIK this is not illegal, and may be done for
backward compatibility some old scripts.

This is the output on my university pc:

X:\>net use
New connections will be remembered.


Status       Local     Remote                    Network

-----------------------------------------------------------------
             W:        \\CLUSTER03_APS01_SERVER\APS01
                                                 NetWare Services
             X:        \\CLUSTER02_USR05_SERVER\USR05\ACC\P133459
                                                 NetWare Services
             Y:        \\CLUSTER02_GRP01_SERVER\GRP01
                                                 NetWare Services
             Z:        \\CLUSTER02_APS01_SERVER\APS01
                                                 NetWare Services
The command completed successfully.

The location of the documents folder is stored in the
HKCU\software\microsoft\windows\currentversion\explorer\user shell
folders\personal registry key/value.

This is not the full story: with group policies registry settings
can be overridden, and I do not know whether the registry editor
show the locally stored value or the effective value.

Also, roaming profiles may be in part implemented by copying files
from the network to the local disk on login and copying back to the
network on logout.

Clicking around in explorer (not IE) under Network eventually gave
me a long list of available shares. According to documentation from
M$, `net share' should display this information but it did not,
therefore I attach a screenshot.

I'll try to find out more, but I am currently recreating my w7
domain member VM which got sick and cranky. And then it will only
be next week that I can have another look at our university network
setup.

Try to find out what really happens to the Documents folder.  Maybe
the solution is [having the admins] create an explicit mapping to a
drive letter.

--
Siep Kroonenberg



More information about the tex-live mailing list