careful before recent MikTex 2.9 upgrade
coo...@nospamverizon.net
most critical of which is that support for relative paths seems to be
completely broken. For example,
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=3,keepaspectratio=true]{../fig1.eps}
\end{center}
\end{figure}
\end{document}
used to compile fine (minutes before the upgrade). Now, can no longer
find the image file. I've confirmed that *anything* that uses relative
paths is now broken.
And yes, I've already set the env variable to allow such 'unsafe things'
as relative paths.
Martin Heller
> used to compile fine (minutes before the upgrade). Now, can no longer
> find the image file. I've confirmed that *anything* that uses relative
> paths is now broken.
From which version did you upgrade? Relative paths to files higher in
the directory structure has been disabled for quite some time due to
security issues.
> And yes, I've already set the env variable to allow such 'unsafe things'
> as relative paths.
Are you saying that setting
MIKTEX_ALLOWUNSAFEOUTPUTFILES=1
doesn't work?
coo...@nospam.verizon.net
Can now confirm that recent MikTeX 2.9 update(s) (not sure what the
offending updated file is) breaks almost everything I use that involves
a relative path (include, includegraphics etc).
wtf?
So, 100% of my thousands of files -- almost all of which use relative
paths for one thing or another -- are now 'broken' (can't be compiled).
coo...@nospam.verizon.net
> On 2011-03-01 18:39, coo...@NOSPAMverizon.net wrote:
>
>> used to compile fine (minutes before the upgrade). Now, can no longer
>> find the image file. I've confirmed that *anything* that uses relative
>> paths is now broken.
>
> From which version did you upgrade? Relative paths to files higher in
> the directory structure has been disabled for quite some time due to
> security issues.
2.9.xxx to 2.9.yyy -- nothing new. And, relative paths disabeld disabled
for some time? Nonsense. My minimal example (below) -- which uses a
relative path to a higher-level directory -- compiles perfectly on
pdfTex 3.1415926 .1.4.011 (MilkTex 2.9). Which I'm doing on the one
machine I have left that I didn't stupidly upgrade.
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=4,keepaspectratio=true]{../figs/fig1.eps}
\end{center}
\end{figure}
\end{document}
>
>> And yes, I've already set the env variable to allow such 'unsafe things'
>> as relative paths.
>
> Are you saying that setting
> MIKTEX_ALLOWUNSAFEOUTPUTFILES=1
> doesn't work?
Correct. It was necessary for \include to work in earlier version (say,
to include chapters), but it doesn't do anything for \includegraphics.
GL
>
> Can now confirm that recent MikTeX 2.9 update(s) (not sure what the
> offending updated file is) breaks almost everything I use that involves
> a relative path (include, includegraphics etc).
I had a similar problem first, and removed MiKTeX and reinstalled it,
taking care to disable the option to use profile dependant pathes.
Otherwise, the texmf directory is quite impossible to maintain (and
its more than a nightmare to search into...) and probably the fndb
becomes a big mess too.
Disabling the option, i now get the same behaviours as version 2.8.
1 texmf directory, 1 localtexmf directory and thats all folks.
If MiKTeX doesn't find some files, think about refreshing the fndb in
administrator mode... better to say it than nothing ;-)
Regards.
coo...@nospam.verizon.net
Partial solution: the latest upgrade to MikTex 2.9 breaks relative patch
in \includegraphics (drat!). However, the 'security fix' that I suspect
is intended hasn't been carried over to \graphics path. So, on a
recently upgraded machine, the following doesn't compile (can't find
fig1.eps -- the relative path problem).
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=4,keepaspectratio=true]{../figs/fig1.eps}
\end{center}
\end{figure}
\end{document}
However, if I used \graphicspath with a relative path (as follows),
example compiles fine.
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\graphicspath{{../figs/}}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=4,keepaspectratio=true]{fig1.eps}
\end{center}
\end{figure}
\end{document}
I still think that Draconian 'elimination' of relative path support is a
bit much. A solution would be to have a compile-time option (or some
such) that let the user decide if they want to live with relative paths
(or not).
So, for the moment, the workaround (which I've only tested on simple
examples -- haven['t tried it on complicated books with lots of
directory nesting and levels of \include) is to use \graphicspath
Peter Flynn
[...]
> Disabling the option, i now get the same behaviours as version 2.8.
> 1 texmf directory, 1 localtexmf directory and thats all folks.
This is interesting. I wasn't aware that MiKTeX had (or was able to use)
a localtexmf directory. Where does it put it?
///Peter
Heiko Oberdiek
> Partial solution: the latest upgrade to MikTex 2.9 breaks relative patch
> in \includegraphics (drat!).
No, you haven't tested it (I couldn't find it in your posts so far):
* Does "\includegraphics{fig1.eps}" work with "fig1.eps" in
the current directory?
This is a relative (trivial) path.
* Does "\includegraphics{figs/fig1.eps} work if
directory "figs" with "fig1.eps" contains right
below the current directory?
This is a relative path, too.
* Does "\includegraphics{../fig1.eps} work if
"fig1.eps" is in the parent directory?
This relative path involves the parent directory that
might be restricted.
If you test it, carefully study the .log file and ensure that
the figre is found in the correct directory. Also generate
a unique "fig1.eps" that doesn't exist elsewhere and
check the output that this unique "fig1.eps" is indeed
used.
> \documentclass[11pt,letterpaper]{article}
> \usepackage{graphicx}
>
>
> \begin{document}
> \begin{figure}[h]
> \begin{center}
> \includegraphics[scale=4,keepaspectratio=true]{../figs/fig1.eps}
> \end{center}
> \end{figure}
> \end{document}
>
> However, if I used \graphicspath with a relative path (as follows),
> example compiles fine.
>
> \documentclass[11pt,letterpaper]{article}
> \usepackage{graphicx}
> \graphicspath{{../figs/}}
>
> \begin{document}
> \begin{figure}[h]
> \begin{center}
> \includegraphics[scale=4,keepaspectratio=true]{fig1.eps}
> \end{center}
> \end{figure}
> \end{document}
But there is another explantion of this success. Maybe, "../figs/"
doesn't exist, e.g. because it's the case or because the current
path is different from that that you expect. And the example
succeeds, because fig1.eps is found elsewhere.
At TeX macro level the graphics package calls \openin
to find the file. The file name is the same in both cases.
--
Heiko Oberdiek
coo...@nospam.verizon.net
> coo...@NOSPAM.verizon.net wrote:
>
>> Partial solution: the latest upgrade to MikTex 2.9 breaks relative patch
>> in \includegraphics (drat!).
>
> No, you haven't tested it (I couldn't find it in your posts so far):
> * Does "\includegraphics{fig1.eps}" work with "fig1.eps" in
> the current directory?
> This is a relative (trivial) path.
Yes.
> * Does "\includegraphics{figs/fig1.eps} work if
> directory "figs" with "fig1.eps" contains right
> below the current directory?
> This is a relative path, too.
Yes
> * Does "\includegraphics{../fig1.eps} work if
> "fig1.eps" is in the parent directory?
> This relative path involves the parent directory that
> might be restricted.
Yes, it does pre-update to MikTeX, not post-update. I tried all these
permutations. relative paths fail, unless you use them in \graphicspath
(an oversight I suspect someone will try to 'fix' in future).
One thing the following text points out is the need for unique (i.e.,
directory-sepcific) file names. If you simply call a figure 'fig1.eps',
and use this name in multiple chapters, you have a problem, because
almost any solution save relative paths will break, because the
compilation won't know which fig1.eps you want. If you use relative
paths, then this isn't a problem.
coo...@nospam.verizon.net
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{fig1.eps}
\end{center}
\end{figure}
\end{document}
..> Compiles fine.
Test 2) move the figure to a subdirectory within the directory
containing the .tex file. Ensure there are no other copies of figure
anywhere
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{figs/fig1.eps}
\end{center}
\end{figure}
\end{document}
..> Compiles fine.
Test 3) move the figure up a level. Ensure there are no other copies of
the figure anywhere.
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{../fig1.eps}
\end{center}
\end{figure}
\end{document}
Pre-MikTeX upgrade: compiles fine
Post-MikTeX upgrade: does not compile
Test 4) create another directory above parent (call it newfigs), put
figure there. Ensure there are no other copies of figure anywhere:
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{../newfigs/fig1.eps}
\end{center}
\end{figure}
\end{document}
Pre-MikTeX upgrade: compiles fine
Post-MikTeX upgrade: does not compile
Summary so far: upgrade breaks relative paths:
Test 5) use \graphics path
\documentclass[11pt,letterpaper]{article}
\usepackage{graphicx}
\graphicspath{{../newfigs/}}
\begin{document}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{fig1.eps}
\end{center}
\end{figure}
\end{document}
Pre-MikTeX upgrade: compiles fine
Post-MikTeX upgrade: compiles fine
Summary so far: relative paths 'broken' for
\includegraphics, not broken for \graphicspath
Problem: suppose you have figures with the same file name in different
directories you'd like to use and re-use in book chapters. For example,
suppose you want to use fig1.eps in the figure director for chapter 2,
and (say) re-use fig1.eps from chapter 1. The path structure might look lik
/book/chap1/figures/fig1.eps
/book/chap2/figures/fig1.eps
Now, what makes the files unique is the directory structure. However, if
you use something like
\graphicspath{{chap1/figs/}(chap2/figs}}
this causes things to fail, because the compilation doesn't know which
fig1.eps you want to use. This wasn't a problem if you could use
relative paths, since (say from within chapter 1) the following sort of
structure
\includegraphics[options...]{figs/fig1.eps}
\includegraphics[options...]{../chap2/figs/fig1.eps}
makes it explicit which fig1.eps from which directory you're trying to
include. I haven't figured out a way to twist \graphicspath to let me do
what I'm describing. Of course, the brute-force solution is to give
unique file names to the images to indicate their directory affiliation
(e.g., ch1-fig1.eps, ch2-fig1.eps, etc), but when you have *hundreds* of
files to rename, you have to wonder if there is a better way.
Like, somehow resurrecting support for relative paths.
coo...@nospam.verizon.net
> Test 5) use \graphics path
>
> \documentclass[11pt,letterpaper]{article}
> \usepackage{graphicx}
>
> \graphicspath{{../newfigs/}}
>
> \begin{document}
> \begin{figure}[h]
> \begin{center}
> \includegraphics[keepaspectratio=true]{fig1.eps}
> \end{center}
> \end{figure}
> \end{document}
>
> Pre-MikTeX upgrade: compiles fine
>
> Post-MikTeX upgrade: compiles fine
>
> Summary so far: relative paths 'broken' for
> \includegraphics, not broken for \graphicspath
>
And, from the TeX FAQ:
(Note that some (La)TeX systems will only allow you to use files in the
current directory and its sub-directories, for security reasons.
However, \graphicspath imposes no such restriction: as far as it is
concerned, you can access files anywhere.)
--> In other words, the fact that \graphicspath worked was 'predictable'
(or would have been if I'd remembered that FAQ entry). Further in the
same FAQ entry is the following useful bit...
The slight disadvantage of the \graphicspath method is inefficiency. The
package will call (La)TeX once for each entry in the list to look for a
file, which of course slows things. Further, (La)TeX remembers the name
of any file it’s asked to look up, thus effectively losing memory, so
that in the limit a document that uses a huge number of graphical inputs
could be embarrassed by lack of memory. (Such “memory starvation” is
pretty unlikely with any ordinary document in a reasonably modern
(La)TeX system, but it should be borne in mind.)
If your document is split into a variety of directories, and each
directory has its associated graphics, the import package may well be
the thing for you;
--> In my case, I have 30 chapters, with 20-30 figures per chapter (in
average), so I'm willing to be that the \graphicspath approach will eat
memory like so much candy. Again, this was never an issue when I could
use relative paths.
So, perhaps I'm off to explore the 'import' package.
Heiko Oberdiek
> Test 1) with fig1.eps in the same directory as the .tex file.
> \includegraphics[keepaspectratio=true]{fig1.eps}
> ..> Compiles fine.
>
> Test 2) move the figure to a subdirectory within the directory
> containing the .tex file. Ensure there are no other copies of figure
> anywhere
> \includegraphics[keepaspectratio=true]{figs/fig1.eps}
> ..> Compiles fine.
>
> Test 3) move the figure up a level. Ensure there are no other copies of
> the figure anywhere.
> \includegraphics[keepaspectratio=true]{../fig1.eps}
> Pre-MikTeX upgrade: compiles fine
>
> Post-MikTeX upgrade: does not compile
>
> Test 4) create another directory above parent (call it newfigs), put
> figure there. Ensure there are no other copies of figure anywhere:
> \includegraphics[keepaspectratio=true]{../newfigs/fig1.eps}
> Pre-MikTeX upgrade: compiles fine
>
> Post-MikTeX upgrade: does not compile
>
> Summary so far: upgrade breaks relative paths:
No, it breaks relative paths that contain the parent directory.
Thus you should check out security settings.
(TeX compiler, dvips, ...)
> Test 5) use \graphics path
>
> \documentclass[11pt,letterpaper]{article}
> \usepackage{graphicx}
>
> \graphicspath{{../newfigs/}}
>
> \begin{document}
> \begin{figure}[h]
> \begin{center}
> \includegraphics[keepaspectratio=true]{fig1.eps}
> \end{center}
> \end{figure}
> \end{document}
>
> Pre-MikTeX upgrade: compiles fine
>
> Post-MikTeX upgrade: compiles fine
>
> Summary so far: relative paths 'broken' for
> \includegraphics, not broken for \graphicspath
There is something more involved.
* What TeX compiler you are using (latex, pdflatex, ...)?
* Which driver is the graphics package using?
Check out the .log file, look for:
Package graphics Info: Driver file: <??>.def on input line ...
What's <??> in your case?
* What's the contents of your graphics.cfg?
* .log file except around the image inclusion?
--
Heiko Oberdiek
coo...@nospam.verizon.net
relative paths, which is a shame (since its so bloody easy to use
them!). So, we substitute simplicity (of relative paths) for... the
\import package (which seems somewhat simple, based on a first go at it
-- famous last words).
Here's an example of what I've managed to get to work based on about 15
minutes of folling-- I'm posting things to (i) have smarter folks
correct any mistakes I'm making (although it seems to compile, which I
acknowledge is not always a proxy for 'doing it right'), and (ii) for
the benefit of anyone else who might run into this issue (there are
precious few examples of using \import that I could find).
1) create skeleton file for book, which will 'include' (in some fashion)
2 chapters
\documentclass[11pt,letterpaper,oneside,onecolumn]{book}
\usepackage{graphicx}
\usepackage{import}
% do not know if the following works with import, so will comment out
%\includeonly{chap1/c1,chap2/c2}
\begin{document}
\mainmatter
\includefrom{chap1/}{c1}
\includefrom{chap2/}{c2}
\end{document}
So, I have a parent directory (which I'll call /book/), with two
subdirectories (one for each chapter: /book/chap1 and /book/chap2). Each
of the chapter subdirectories contains a figs/ directory:
/book/chap1/figs and /book/chap2/figs
2) each of the two chapters \includes some graphics that are contained
in the figs/ subdirectory within each chapter folder.
c1.tex looks like
\chapter{}
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{figs/fig1.eps}
\end{center}
\end{figure}
and c2.tex looks like
\chapter{}
Here is figure 1
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{figs/fig1.eps}
\end{center}
\end{figure}
Here is figure 2
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{figs/fig2.eps}
\end{center}
\end{figure}
Here is figure 1 from chapter 1, re-used.
\begin{figure}[h]
\begin{center}
\includegraphics[keepaspectratio=true]{chap1/figs/fig1.eps}
\end{center}
\end{figure}
..> note that I set up c2.tex to make calls to image files that are in
separate directories, but which have the same file name (fig1.eps, in
this example). This is the sort of thing that can cause problems for
\graphicspath (amongst other limitations).
Compiling the skeleton works fine. I haven't entirely sussed out the
difference between the \includefrom and \subincludefrom directives in
the skeleton file (since for this example, using either or makes no
difference), but this seems to work and (praise Donald Arseneau for the
import package) might eliminate the need to rename hundreds of graphics
files.
Comments/corrections welcome.
Ulrike Fischer
> This is interesting. I wasn't aware that MiKTeX had (or was able to use)
> a localtexmf directory. Where does it put it?
Miktex installs at least two texmf-trees in the user profile beside
the main tree: the one call UserData (for generated files like pk,
fndb etc) and UserConfig (for local config files). In multiuser
setups there are also CommonData and CommonConfig.
Beside this you can create new texmf tree as you like and mount them
(and remove them without fuss it if you no longer need them). So you
can have more than one "localtexmf". In general I have 3-4 such
local trees active. One with my standard local files, the others
contain e.g. beta version of packages.
--
Ulrike Fischer
Ulrike Fischer
coo...@NOSPAMverizon.net:
> Doing the latest 2.9 upgrade to MikTeX seems to break several things --
> most critical of which is that support for relative paths seems to be
> completely broken.
No, broken were absolute pathes and relative pathes including parent
directories. Relative pathes to subfolders worked still fine.
Looks as if miktex used a setting similar to the texlive "openany=p"
(paranoid).
With the newest update the problem has been solved.
--
Ulrike Fischer
Peter Flynn
> Am Wed, 02 Mar 2011 00:00:25 +0000 schrieb Peter Flynn:
>
>
>> This is interesting. I wasn't aware that MiKTeX had (or was able to use)
>> a localtexmf directory. Where does it put it?
>
> Miktex installs at least two texmf-trees in the user profile beside
> the main tree: the one call UserData (for generated files like pk,
> fndb etc) and UserConfig (for local config files). In multiuser
> setups there are also CommonData and CommonConfig.
I'm not very familiar with Windows: where is "the user profile"? I know
that MikTeX wants to install in C:\Program Files\MikTeX 2.8\... (or,
presumably, 2.9). Is the user profile the directory called "My Documents"?
> Beside this you can create new texmf tree as you like and mount them
> (and remove them without fuss it if you no longer need them). So you
> can have more than one "localtexmf". In general I have 3-4 such
> local trees active. One with my standard local files, the others
> contain e.g. beta version of packages.
Very useful, thank you.
I had some students run into trouble yesterday trying to install proTeXt
fom the TC2010 DVD because they were using 64bit HP laptops. The
installation started OK, but aborted half-way through. Unfortunately I
wasn't there to see if there was an error message, but the result was
half an installation. Is there a 64bit version? Or a method to make the
32bit version work?
///Peter
Peter Flynn
[...]
> I had some students run into trouble yesterday trying to install proTeXt
> fom the TC2010 DVD because they were using 64bit HP laptops. The
> installation started OK, but aborted half-way through. Unfortunately I
> wasn't there to see if there was an error message, but the result was
> half an installation. Is there a 64bit version? Or a method to make the
> 32bit version work?
I see in a later post that 2.9 apparently works in 64bit Windows 7.
I'll suggest they delete their 2.8 and install 2.9, thanks.
///Peter
GL
> On 02/03/11 08:04, Ulrike Fischer wrote:
>> Am Wed, 02 Mar 2011 00:00:25 +0000 schrieb Peter Flynn:
>>
>>
>>> This is interesting. I wasn't aware that MiKTeX had (or was able to use)
>>> a localtexmf directory. Where does it put it?
>>
>> Miktex installs at least two texmf-trees in the user profile beside
>> the main tree: the one call UserData (for generated files like pk,
>> fndb etc) and UserConfig (for local config files). In multiuser
>> setups there are also CommonData and CommonConfig.
>
> I'm not very familiar with Windows: where is "the user profile"? I know
> that MikTeX wants to install in C:\Program Files\MikTeX 2.8\... (or,
> presumably, 2.9). Is the user profile the directory called "My Documents"?
No, \Documents is under C:\Users\<Name>\
Under Windows 7 you get:
C:\Users\<Name>\Local
\LocalLow
\Roaming
C:\Users\<Name>\Local\MiKTeX\2.9 stores the .pk fonts
C:\Users\<Name>\Roaming\MiKTeX\2.9 stores the config
(updmap.cfg for example)
I don't remember exactly but I think the local user dependent texmf
directory would be under \Roaming rather than \Local. (i'm not sure ;-)
Anyway at intallation time you choose the main directory. You're free in
this choice (provided you are granted enough upon the file system)
(i prefer c:\texmf than c:\Program Files (x86)\MiKTeX\2.9\....)
Then you may choose to create user profile dependant directories or not.
I prefer not because, as Ulrike said, you can choose another directory
as well, for example c:\localtexmf, in the MiKTeX options (in admin
mode).
If every user is granted to read and possibly write on c:\localtexmf
then this directory stores the local stuff for everyone: it replaces
each C:\Users\<Name>\Roaming\MiKTeX\2.9\...
For me this is simpler to manage. The .tex documents can always be
folded anywhere, usually under \Users\<Name>\Documents\...\...\...
Yours sincerely.
Ulrike Fischer
>> I'm not very familiar with Windows: where is "the user profile"? I know
>> that MikTeX wants to install in C:\Program Files\MikTeX 2.8\... (or,
>> presumably, 2.9). Is the user profile the directory called "My Documents"?
>
> No, \Documents is under C:\Users\<Name>\
> Under Windows 7 you get:
> C:\Users\<Name>\Local
> \LocalLow
> \Roaming
>
> C:\Users\<Name>\Local\MiKTeX\2.9 stores the .pk fonts
> C:\Users\<Name>\Roaming\MiKTeX\2.9 stores the config
> (updmap.cfg for example)
>
> I don't remember exactly but I think the local user dependent texmf
> directory would be under \Roaming rather than \Local. (i'm not sure ;-)
There is not "the" local texmf tree as you can have a lot of local
texmf trees.
Apart from this: The main difference between \Local\ and \Roaming\
is that in a network the windows server is supposed to backup/save
the roaming tree when you logout, so it it certainly the better
place for files you want to keep.
> Then you may choose to create user profile dependant directories or not.
> I prefer not because, as Ulrike said, you can choose another directory
> as well, for example c:\localtexmf, in the MiKTeX options (in admin
> mode).
You can not choose not to create the miktex trees. It needs a place
to store pk-files and local config files (opened with initexmf
--edit-config-files). You can at installation only choose their
location. If you delete the miktex trees (which I never did), miktex
will either get thoroughly confused or recreate them as soon as they
are needed.
> If every user is granted to read and possibly write on c:\localtexmf
> then this directory stores the local stuff for everyone: it replaces
> each C:\Users\<Name>\Roaming\MiKTeX\2.9\...
There is no need to "replace" something. C:\localtexmf can be
created and added to miktex beside the other roots.
>> I had some students run into trouble yesterday trying to install proTeXt
>> fom the TC2010 DVD because they were using 64bit HP laptops. The
>> installation started OK, but aborted half-way through. Unfortunately I
>> wasn't there to see if there was an error message, but the result was
>> half an installation. Is there a 64bit version? Or a method to make the
>> 32bit version work?
I never used proTeXt.
But I had no problems to install miktex 2008 on win7+64bit in a
restricted account as single user. I never install the full version
but always the basic version, I add additional packages later with
the package manager as needed. This avoids troubles if one package
is crappy. Also: even if the installation didn't end: Always test if
it works anyway. Often only some small cleaning up at the end fails.
Like fc-cache.
--
Ulrike Fischer
Robin Fairbairns
> Apart from this: The main difference between \Local\ and \Roaming\
> is that in a network the windows server is supposed to backup/save
> the roaming tree when you logout, so it it certainly the better
> place for files you want to keep.
except that the reloading/backing up can then come to dominate log
in/log out time. we gave up on roaming profiles because users would
stuff their profile with loads of huge documents, etc., and then
complain about login/logout time.
we now have have the central file store hold the profile (rather than
machine-local disc, with copying to the server), and logging in/out is a
lot faster than it used to be. (i'm not sure how all this is done; i've
stopped being an "official" windows administrator.)
--
Robin Fairbairns, Cambridge
my address is @cl.cam.ac.uk, regardless of the header. sorry about that.