Curious

[chris635]

Hey bud,

    Are you still supporting this? I'm thinking about using it to control googles picasa cache. It defaults to appdata/local and cant change internally. Would this be a good alternative to move that folder and junction to it?

[chris635]

I went ahead and tried it. It will not move the google picasa cache for the appdata\local folder. I get errors.

[chris635]

Okay so junctionmaster doesn't work with Google picasa cache, works with everything else. It says the folder in use or it's protected. Any way around this?

[Jeremy Collake]

I would have to evaluate this legacy project.

Some people have attested to it really benefiting them.

Thus, there is some small market here. I believe I can capitalize on it with a little maintenance work.

[chris635]

Okay. I got it to work with the cache. It wouldn't work with the whole Google folder. JunctionMaster  has great potential.

[Jeremy Collake]

You don't prefer my alternate name of 'MoveAndLink' . LOL, dunno what I was thinking.

Yes, I will at least take basic steps to make sure this project is up to date.

[chris635]

You don't prefer my alternate name of 'MoveAndLink' . LOL, dunno what I was thinking.

Yes, I will at least take basic steps to make sure this project is up to date.

lol!     Yes I'm really liking this.

[chris635]

Once you learn how to use this, it works great! I know your busy with PL..ie development and marketing and such, but, when do you think you will be able to update this? Not that it really needs it LOL!

[Jeremy Collake]

It's on the radar for sure, I do intend to update it.

One of the things that needs done, before I feel really confident in it, is additional safeties. I just don't want people coming to me saying they lost data, which is why I put warnings all over the software.

RegMerge is also very cool, and I've got it down completely right now because of a bug concern. Again, since the registry is so critical, gotta get it out of alpha before release.

Probably I'll tackle these sooner rather than later. Lasso is at a branch point anyway.

[chris635]

Sounds good!

[chris635]

Jeremy,

     On files that I have moved. When I need to up date them (for whatever reason). Will the junction work correctly?

[Jeremy Collake]

Yes, of course. Assuming I haven't misunderstood. I use junction points extensively on my systems, just a shortcuts to common paths and such. They are just basically 'pointers', so the files there get updated no matter from which path you reference them from.

[chris635]

Okay..Thanks!  The only problem I have encountered...we'll not really a problem I guess. I use Tera copy, for copying or moving files faster. I have it set to replace windows as the default file handler. Junction master will revert my system back to windows for handling file moves (after I have used Junction Master for a junction point). I then have to go back and re set it for Tera Copy.  Works great though.

[motechman]

Jeremy -

thanks for creating this tool. I wrote a Windows batch file to do this (was going to do it in WSH / JScript but it was actually easier, tho less robust in cmd batch) which I tested and works quite well. I opted to copy the source folder to the destination, rename the source folder then create the symbolic link (i.e. junction point in Micro$oft lingo). That way if for whatever reason the relocation causes issues all you have to do is delete the link and rename the source folder back to the original name.

I had no issues at all using that cmd file on items in the "Program Files" folder, but it would not work in the "Program Files (x86)" folder because the security policy prohibits renaming there, even for admins. I find that strange but not surprising, afterall it's Micro$oft we're talking about.

Mico$oft's security model is terrible. *nix has a much better model with the default policy of no access to anyone for anything and all access must be explicitly granted. Micro$oft suffers from the "daze of DOS" legacy policy where everything was wide open by default. As DOS evolved into generations of Windows additional security was added out of necessity, but it was constrained by legacy considerations. *nix systems were designed from the start with security in mind.

I much prefer *nix systems. They're more efficient, flexible and robust. If it weren't for the few apps I need like Dragon Dictate and the huge installed base of Windoze systems and their users that rely on them, I'd never boot windows again.

Although the symbolic link functionality is now built into the NTFS filesystem, which should allow the same flexibility as *nix systems have for filesystem space management, Micro$oft in their dictatorial "wisdom" has chosen not to provide the tools for end users to use symbolic links to relocate things easily according to user preferences. That approach does have the advantage however to standardize the location of things, which simplifies troubleshooting and maintenance.

That's the one thing about using symbolic links which is nice, since they work at the filesystem level and are transparent, they work for all but a few cases, such as user profile folders. It should work for that too, but that just tells me Micro$oft code is not engineered all that well.

Now that I've discovered your JunctionMaster tool I can retire my simple cmd script.

Thx again!

[Jeremy Collake]

I'm glad it helped .

You're right, the failure for Microsoft to add FULL support, e.g. in Explorer's file system view, makes junctions/symlinks hard to use in Windows, and easy to make mistakes with. Honestly, I think Microsoft execs decided their users weren't smart enough to handle them. That's my theory anyway.

Of course, Microsoft has made a lot smarter decisions of late, so maybe it is a dawn of a new age.

I run a lot of linux systems as well. It has it's advantages, but so does Windows.