[Genma Saotome]

I did a test the other day... put a shortcut into \trains at the directory level that pointed to another directory on another disk, the later holding all of the actual files you need to define a car. I then edited a consist file, referenced the .wag name and the shortcut name. I was hoping OR would simply follow the shortcut over to the other disk and pick up the necessary files. It did not (this may have been a user error but I'm pretty sure I did this correctly).

Which leads to my questions: Why can't OR follow the instructions in the shortcut?


As for why, I've been trying to solve the many to many relationship that exists between n minroutes and n cars -- the problem of having to copy the same car files to each miniroute. It's not a copy or size problem so much as what happens when you edit the car files? THEN all those copies turn out to be a real PITA.

With shortcuts it could be something like this:



The directory tree on the left could take any form you want while over on the right the same structure we're all using from MSTS. ALL of the directories on the right are shortcuts that point to the left. This way there is only one instance of each set of car files. You make one update and that is it... not copying anywhere.

[burgerbern]

That would be very useful, i edited a folder of wagons the other day and then had to hunt through 45 mini routes to see if i had used the same in any of the others, turns out i had in 16 of them. its not a space issue i have 2.5TB to play with but as Dave said one of keeping multiple instances of cars and engines synchronised to the latest build or update.

[Goku]

Genma Saotome, on 15 September 2015 - 05:40 PM, said:

Which leads to my questions: Why can't OR follow the instructions in the shortcut?

OR can't because old Windows 'shortcut' is file.lnk not link to another directory.

In windows ntfs filesystems you can make real 'shortcut' like in unix systems. It's called 'symbolic link' and if you make it that way everything will be working as you want.

Here is example how to do it: http://www.howtogeek...ndows-or-linux/

Quote

Want to easily access folders and files from different folders without maintaining duplicate copies? Here’s how you can use Symbolic Links to link anything in Windows 10, 8, 7, Vista, XP, and Ubuntu.

It's funny that better way of making 'shortcuts' exist in windows for 16 years but they still use old, useless '.lnk' way as default.

[James Ross]

Genma Saotome, on 15 September 2015 - 05:40 PM, said:

I did a test the other day... put a shortcut into \trains at the directory level that pointed to another directory on another disk, the later holding all of the actual files you need to define a car. I then edited a consist file, referenced the .wag name and the shortcut name. I was hoping OR would simply follow the shortcut over to the other disk and pick up the necessary files. It did not (this may have been a user error but I'm pretty sure I did this correctly).

Which leads to my questions: Why can't OR follow the instructions in the shortcut?

I'm assuming you're using Junction Points here, and not what Windows calls a shortcut (which is a .LNK file as Goku says).

The key thing to remember with setup like this is that Junction Points are invisible to the application, so all path operations are on whatever original path was used to access them. E.g. if you go up a level, you're going up a level in the original path. This means that when a wagon references "..\\Common.Snd\\whatever.sms" it will be looking for it in the mini route's Trains folder.

If you're aware of the above and have accounted for it, I see no reason for it not to work, so perhaps a concrete example and indication of the failure would be useful.

[Genma Saotome]

I know and use Junctions (I populate multiple miniroutes with the same route, leaving \trains to be local and unique).


Goku suggested symbolic links, which are, for one PC, equivalent enough to junctions that the basics of the concepts are identical and so as far as understanding goes, they're fine. What feels different is there are

• so many folders inside of \trains.
  
• so many of them are duplicated in n number of miniroutes.
  
• not created as easily as are shortcuts, which are familiar to everyone.

IOW, my reservation over so many links is primarily administrative in nature -- a bit harder to set up -- and only then technical: is it really ok to have a thousand or so symbolic links? How do you backup the link itself?

[James Ross]

It's completely fine to have thousands of Junction Points and/or (file and directory) Symbolic Links - they're all stored in the same way, ultimately, as a special file/directory whose contents in the pointer to another location.

That said, I'm not sure of any particularly good way to back them up - most backup tools will or can ignore Junction Points/Symbolic Links to avoid duplicating files, but keeping the link itself seems uncommon. I've previously done something like this, as a painful-to-restore backup:

dir /s | findstr "Directory <JUNCTION <SYMLINK"

You may also be able to use the SysInternals Junction tool at least for Junction Points.

[burgerbern]

OK i just tried a different approach, i did not try to reference a special folder on another drive letter as Dave is trying to do, but i did set up a directory structure outside of MSTS on the same drive letter as the 45 Mini Installs, i then referenced that set of folders in a consist file from a mini install that did not actually have a copy of the wagons in it (so that if it appeared i knew it was from the remote location) and after a couple of revisions it worked the drive H is 500GB in size and has a fraction over 250GB's worth of files on it, if all the multiple folders of equipment (IE those that exist in more than one miniroute ) could be referenced from one location A: space would be saved and B: when any updating was done it would be instantly available to all mini routes thar referenced it. I used my Sandpatch mini for the test which has 4 routes in it and the folder i had created where all the SLI 50ft std boxcar types are stored.

the mini install is H:/Microsoft Train Simulator Sandpatch

and the new wagon folder was at h:/Trainset_Master/Boxcars/50ft_Boxcars_Mixed_SLI

the consist file line looked like this

WagonData ( RBOX_32226_LD ..\\..\\..\\Trainset_Master/Boxcars/50ft_Boxcars_Mixed_SLI )

Tested it in OR and it worked the consist showed up with the boxcar and i know it was the boxcar from the remote master folder as that folder did not exist in the Sandpatch mini install

i also fired up MSTS with BIN but in that, as suspected it came up as an error as MSTS loaded, that the wagon could not be found

so although it will take some time and i only need to do it to folders of equipment that would be appropriate to more than one mini, stuff like Trailer Train equip as one example if i start setting up new stuff from here on in and older stuff as and when it is used, eventually it will make things a bit tidier on the hard drive and give some space back.

[markus_GE]

EDIT: All point below already mentioned

As pointed out, symlinks are a viable alternative.

Also, why don´t you just place a junction in the mini-routes? "Shortcut A" in your above draft would then read "Junction A"; same for B, C, etc.

Cheers, Markus

This post has been edited by markus_GE: 16 September 2015 - 12:39 PM
Reason for edit:: Forgot to reload the page after having had it open for hours - all point below already mentioned

[markus_GE]

I am aliasing cabs and sounds from two Common.* directories by placing hardlinks in the relevant folders of a locomotive / car folder, and typing the filename in the ENG file. Moves those lengthy alias paths into the CVF / SMS (viewed less often) and makes it easier (a least for me) to do the aliasing - all I need to do is use Link Shell Extension (shell-integrated Link creation tool) to create the links :)

WRT backing up junctions, links, etc. - what does e.g. robocopy do with those?

Cheers, Markus

[Genma Saotome]

burgerbern, on 16 September 2015 - 11:07 AM, said:

...and the new wagon folder was at h:/Trainset_Master/Boxcars/50ft_Boxcars_Mixed_SLI

...the consist file line looked like this

WagonData ( RBOX_32226_LD ..\\..\\..\\Trainset_Master/Boxcars/50ft_Boxcars_Mixed_SLI )

Well if something were to be done in the .com file I would prefer something that allows you to specify the path with a token, something like this:

$PATH A = h:\Trainset_Master\Boxcars\
$PATH B = H:\Trainset_Master\Reefers\

followed by
WagonData ( RBOX_32226_LD $A\50ft_Boxcars_Mixed_SLI )
WagonData ( SFRD_54321_LD $B\RS_SFRD_Rr40 )


There might be a few path statements in each .con file that way but IMO it'll still be easier to understand and do than repeat as needed until its undecipherable "..\\". It would also be vastly easier to relocate or restructure the master library with any editor that could do file search and replace (e.g., replace "Path A = h:\Trainset_Master" with "Path A = D:\My_Roster" in files *.con in fileset "E:\Open_Rails_Mini_1\trains\consist"). That certainly addresses all concerns about backups and IMO does a better job that relative paths because it allows the end user to have his own solution as to where his master library is located as well as how it is structured. IOW the benefit of a symbolic link w/o its issues. What is lost relative to the symbolic link is being able to edit something in the miniroute and have it propagate back into the library and on to all other places. But hten, if implemented, \trainset in the minirotues would be empty anyways.

[James Ross]

markus_GE, on 16 September 2015 - 12:43 PM, said:

WRT backing up junctions, links, etc. - what does e.g. robocopy do with those?

RoboCopy defaults to "following" junctions and symlinks, which means you get the target file's contents at the source location (i.e. a duplicate). It does have options though:

• /XJ :: eXclude Junction points. (normally included by default).
  
• /XJD :: eXclude Junction points for Directories.
  
• /XJF :: eXclude Junction points for Files.
  
• /SL :: copy symbolic links versus the target.

The first three simply exclude them, so you'll just not have the directory/file which is junctioned/symlinked to somewhere else, while the third will actually copy the symlink (presumably only if the target location supports them, i.e. probably not on to most USB sticks).

Hard Links are (yet) another thing, and will pretty much always copy as normal files (RoboCopy has no options for them, and it doesn't really make sense to have options for them).

[markus_GE]

:sign_thanks: for the info, James :)

So, let´s make this more complicated - said shell-integrated file linking helper program "Link Shell Extension" (easily found on Google) includes an extension to Windows File Explorer´s copy program, called "Smart Copy". It enables the explorer to preserve links when copying. Can something like that be achieved with robocopy as well?

Cheers, Markus

[James Ross]

markus_GE, on 16 September 2015 - 01:18 PM, said:

So, let´s make this more complicated - said shell-integrated file linking helper program "Link Shell Extension" (easily found on Google) includes an extension to Windows File Explorer´s copy program, called "Smart Copy". It enables the explorer to preserve links when copying. Can something like that be achieved with robocopy as well?

Looks like you can do it with the same site's "ln" tool (--copy). As for RoboCopy, I've not tested it (so YMMV) but AFAICT symlinks are relative by default, so if you have "inner symlinks" I think they'll copy fine with the "/SL" option. "Outer symlinks" will probably copy as well but then be pointing to the wrong location (because they're relative) so you'll need to fix them. Junction Points are (IIRC) absolute by default so the opposite applies. Hard links are unlikely to be copied at all.

[markus_GE]

:wallbash: I´ve used ln.exe multiple times already to achieve exactly that.

:sign_thanks: for straightening my chain of thought there, James :)

Cheers, Markus

[Genma Saotome]

A bit more info... if you change your Windows explorer display to show the value of "Attributes" for your directory listing it will display the letters:

RD -- for any directory being used as a physical source directory, meaning these are real files in their real location.
DL -- for any directory being used as a linked directory, meaning this is a logical link that points back to a physical source directory.

If you also add "Link Target" it will give you the path and directory name of the physical source directory for any "DL" directory.


Any adds, file edits, deletions in either the source or linked directory will be reflected immediately in the other -- they are all the same thing.

Also, it seems if you drop a symbol link into a directory that already has the same name the new link will be named "abc - symbolic link" (where abc is the duplicated name). This makes it easy to find and correct -- just delete the original directory and rename the link by removing " - symbolic link".