LDraw installation folder

[Jetro de Château]

Traditionally LDraw has always been installed under C:\LDraw on Windows machines.
I never liked the idea of placing it directly under C.. somehow it seemed unorganised and made more sense under Program Files. The AIOI does just that and on my Windows / machine creates the LDraw folder under C:\Program Files (x86)\LDraw. This has 2 drawbacks though.

First of all, the AIOI is used by many people who want a simple, fast out-of-the-box LDraw installation. But when they want to update the parts library they find the proposed installation path given by the executable LDraw.org provides is the traditional C:\LDraw. They are unlikely to remember where the AIOI installed everything and if they simply go ahead and install the update will not show up in their MLCad.

Secondly, if they are clever enough to use LDView to update their library they run into another problem: LDView will throw an error and not install the update. The reason is that LDview has no admin rights to make any changes to the installation folder and so cannot install the update. In order to fix this a user needs to go into C:\Program Files (x86)\LDraw and remove the "read-only" option for that folder and all files and folders included in it.

I have addressed this issue on the HispaBrick Magazine blog.

Neither of these situations is ideal. Granted, LDraw users might be expected to have some computer skills, but ideally LDraw should be accessible to anyone without the need to know these things.

I don't know which location is preferable for LDraw (C:\Program Files (x86)\LDraw or C:\LDraw) but it would make sense to help users as much as possible to avoid any confusion. Maybe the LDraw.org update could include an AIOI option to make sure files are installed at the right location.

At the same time, maybe it is possible for the AIOI to change privileges for the installation folder so as to ensure that LDView can actually carry out a parts update without running into problems.

Neither of these two situations is ideal.

[Steffen]

I have a different setup (Windows 7 64bit):

The LDRAW installation placed here:

C:\Users\XYZ\Documents\LEGO\LDRAW\MODELS <-- here go my unofficial files
C:\Users\XYZ\Documents\LEGO\LDRAW\PARTS
C:\Users\XYZ\Documents\LEGO\LDRAW\P

My scenes, models etc go here

C:\Users\XYZ\Documents\LEGO\Playground\...

And finally here go the programs:

C:\Users\XYZ\Documents\LEGO\Programs\...

There, for example, I have parallel installations of 3 MLCad versions in folders

C:\Users\XYZ\Documents\LEGO\Programs\MLCad 3.20
C:\Users\XYZ\Documents\LEGO\Programs\MLCad 3.30
C:\Users\XYZ\Documents\LEGO\Programs\MLCad 3.40

I'm unsatisfied with putting the programs there, but
when I had installed the programs to
C:\Program Files
C:\Program Files (x86)
, some of them failed to run because they tried to write into their installation folder.
Nowadays, maybe some of them don't anymore, but I don't wanna change my setup now that it is working.
Installing the programs to my LEGO folder allows me to easily grep for files,
even when they are buried in e.g. SR3D's program folder.

And in
C:\Users\XYZ\Documents\LEGO
, I can even store non-LDRAW files like building instructions, photos, videos etc.,
each in its own subfolder.

Well, just a virtual LEGO collection :-)))

[Jetro de Château]

Interesting, but hardly "standard"

Unofficial files are expected to be in LDraw\Unofficial and the rest of your installation mimics the "old" C:\LDraw setup which also contained an "Apps" folder inside which different versions of MLCad could live side by side without any problem.

I still need to get the hang of SR 3D so I can't comment on its folder structure, but maybe you have experienced something similar to what I described concerning LDCad where I couldn't find files I had saved because Windows wouldn't let the program save the files to the default location and diverted them to a user specific location buried deep in the system. This was solved by unchecking the "read-only" option in the properties for the LDcad installation folder.

Bottom line: installing to C:\Program Files (x86) causes a lot of issues unless the folder is correctly made accessible by the program. If that cannot be done, maybe a different solution needs to be found.

[Orion Pobursky]

Per Microsoft's own guidelines, anything that a program can edit should be placed in a directory in the User path. This is why user options are stored in the App Data directory. I just lump everything into C:\Users\<User Name>\Lego and that seems to work fine for me. This is also the reason I like zip files instead of installers.

[Jetro de Château]

That would mean duplicating installations on systems with multiple users... although the chances of that occurring are negligible.
The reasoning behind this is sound, so should LDraw consider recommending this as the preferred installation location and adapt its installers accordingly?

[Orion Pobursky]

The "correct" way would be to place the programs in "Program Files" and the Library in either the Public profile "App Data" or "Program Files" as well. The user specific stuff (preferences, settings, etc) is supposed to go in that user's "App Data" and the model files, etc in Documents.

[Steffen]

yep

[Roland Melkert]

This is the correct way indeed, but I always hate the fragmentation this results into, especially with small programs/tools, e.g. :

Just a lonesome exe in program files and a single cfg file way over in the user dir, and gen library/bin/template files in lock down at appdata.

It's weird though, cause in Linux this (seems) less of a burden.

[Jean-Philippe Ouellet]

It's no more fragmented than having your programs in /usr/local/bin, your parts library in /var/ldraw or /usr/share, your configuration in /etc/ldraw or ~/.ldraw and your files saved someplace within your home directory. Standard paths are all created with specific usages in mind, I believe it only makes sense to follow them.

On Mac the programs are in /Applications, the library in ~/Library/LDraw or /Library/LDraw, the config in ~/Library/Preferences or /Library Preferences. Sure, not all your LDraw stuff is contained within one master directory, but why should it need to be? Are you trying to hyper-simplify installing/removing it by just having one folder to delete? (we have an installer/uninstaller already...) What is the real gain of having everything in one folder?

You wouldn't want sort(1) to write temp files to /usr/bin would you? I know its an oversimplified example, but it's the same principle.

As for old closed source programs which I don't have control over where it expects things to be, I just create a symlink (alias, shortcut, whatever you want to call it) to where it actually makes sense for my files to be stored.

Having actively avoided Microsoft since windows 98 I really can't speak for the non-unix-based world, but having different types of files in different places depending on the minimum required permissions makes perfect sense to me.

[Tim Gould]

*nix is ridiculous for organisation. Everything has its own weird place which may have made sense in 1975 on a 'supercomputer' but doesn't make much sense on a home PC. Windows is much more sensible for home use IMO.

That said, I make complicated tree structures by choice so I can complain about neither.

Tim

[Roland Melkert]

I'm all for splitting data and binaries but to me this is more fore big (100MB+) applications, for small tools it seems a bit much.

Also having everything in one place makes the application mobile, something that makes it extremely easy to setup a LDraw flash drive or dvd.

[Anders Isaksson]

The "correct" way would be to place the programs in "Program Files" and the Library in either the Public profile "App Data" or "Program Files" as well. The user specific stuff (preferences, settings, etc) is supposed to go in that user's "App Data" and the model files, etc in Documents.

Assuming the program is following the Win7 rules, yes. If not, it's an 'old' program. My recommendation to anyone installing 'old' programs is to create a folder, C:\OldPrograms, and install there. Everything will continue to work as it did in older versions of Windows.

[Orion Pobursky]

Actually that's the way Microsoft has been recommend since I think Win 98. They just started enforcing it better from Vista on.

[Anders Isaksson]

Actually that's the way Microsoft has been recommend since I think Win 98. They just started enforcing it better from Vista on.

I'm not completely sure what "that's" is referring to in your sentence. What I was saying was that if a program isn't explicitely written to conform with the Win7 rules, it will probably not work as expected if installed in \Program Files, as (both Vista and) Win7 does its funky virtualization for such programs, fooling the program that it has the right to write data in \Program Files, while silently redirecting the files to a hidden folder deep down in the <user> hierarchy. Any attempt to backup things by copying the folder in the \Program Files hierarchy (or use the program logged in as another user) will fail miserably, as the files are not physically there (even though it may look like that when the program is run). Library updates will also be a difficult process, as you may install new files but are not allowed to replace existing ones (unless you run an installation program, or unpack a .zip file by running unzip with elevated privileges).

Any program that doesn't have the right manifest in its resources will be treated as an 'old' program by Windows if running from \Program Files, and should preferrably be installed outside of that hierarchy. If it has the manifest, but "doesn't live up to its promises" it will also fail.

[MsGtx]

I'm a newbie and I'm not sure why I'm not finding a more recent/current discussion of this problem, but...

I just had a number of confusing problems with installation paths on Win 10. (not my choice of OS, so don't even go there)

It took me a while to find this particular thread, and I finally got it sorted out, but ...

I understand everything said above about folder structures and permissions and I can tell you that, if you are installing on multi-user, networked machines with Windows user profiles (as in most schools), the current MS/Windows prescription to separate out user-writable directories/libraries is an absolute must. Our school IT support dept would have a fit (or at least drag their feet) if they had to customize the install directories and/or make the C: drive write-able by users in order to install this.
(It's OK if we just stick to LDD for lower grades, but I'd like to see high-school students trying LDraw.)

Just installing on a laptop where I have admin rights, I've found out (the hard way) the many ways one can go wrong with directory paths, especially if you try to separately install components such as the parts library.
(To spare you a long story, something failed in the AIOI or else I didn't understand what the correct choice was supposed to be when prompted to identify where the parts library was the first time; it certainly wasn't in the default LDraw folder that appeared in the dialog).

I know that installers and install options are a pain to develop, but it might at least help if there were clearer instructions/documentation on the default vs. possible vs. preferred options are for installing which components in which directories in which OS/environments. Is everything supposed to be in one "base" LDraw folder or not?

To sum up, is it fair to say that the parts library could be installed to any chosen location as long as:

• the location of the parts library files must be within a folder named LDraw
  
• the user(s) must have write-permission to this folder
  
• the user(s) must know/identify the location of this folder when launching any particular app (MLCad or LDView etc)
  

...?
And is this only/mainly true of the parts library? (because that is the main folder that has to be updated &/or written to regularly?)

Again, sorry, I am a newbie!

[Willy Tschager]

Hi MsGtx,

you've got a point. Currently the AIOI installs all programs by default to:

c:\Program Files (x86)\LDraw

but you might change this. In addition the LDraw Parts Library will be installed to:

C:\Users\Public\Documents\LDraw

to allow programs modifying "Parts.lst" or LDView automatically download parts to that folder. The installer writes this path into the Registry keys for several programs such as MLCad, LDCad, LDview, LPub3D, ... or .xml such as ldfindini.xml

I'll look into the installer and check how much overhaul is needed to make this location customizable.

w.