Reaper doesn't understand junctions (FIXED)

[Airal]

I use a junction to deal with project complications. Reaper doesn't understand that two paths that point to the same place are identical. Instead, it saves duplicate files to the exact same location with a file increment.

e.g.,

C:\Projects\MyProject
A:\MyProject (A junction pointing to C:\Projects\MyProject)

When loading a project from the first path then saving it to the second path, reaper duplicates(with file increment) all the files.

Suggestions:

1. Resolve the junction to see if it is the same path as the save path

2. Check if the files being duplicated already exist and ask to use them(could do a binary compare or something).

(I noticed this because of a crash and I loaded the project from the non-junction path, when I saved the project, reaper "converted"/"saved" all the items to the "new" path)

[Justin]

There's a reason junctions aren't really used much on Windows

[kenz]

I actually like that most applications don't care about links/junctions. I love to use symbolic links/junctions for custom organization, especially when apps have no clue about them so their usage can be very predictable.

They can be used for "compatibility" too. If the app is unaware, you can just use an abstract path say, C:\Projects, and then it can reside anywhere literally. Reaper will know it's in C:\Projects because that's where you open it from; and it will still work even if you change paths later. Just be sure to open them from C:\Projects and not the actual path.

I use symbolic links / junctions extensively.

[Justin]

A better solution is probably to detect identical files...

[mschnell]

Originally Posted by Airal

Suggestions:

1. ...

2. ...

3. (What I do) Hold the files on a Linux Server (i.e. a NAS), Here you can do hard and soft links as appropriate.

-Michael

[Airal]

It should be quite easy to get the junction target and compare it to the saved path target. If they are the same, then just use one or the other(shouldn't matter with relative paths I imagine). Might have to recurse for junctions of junctions.

One could do a binary check of the files, in fact, it might be a good idea to "reuse" files but I think it would require a full binary compare for safety but could be slow in some cases.

I'm like Ken, I use junctions all the time for similar reasons. I don't see why getting the *real* path that the project was opened in and the *real* path that it is being saved in, and if they are the same, do not create extra files. Seems like something rather trivial?

[Justin]

I think doing what you describe is actually quite complex -- a binary compare of the files is preferable IMO, since a) obviously different files will be determined quickly, and b) exactly the same files will still avoid a copy.

[Airal]

Originally Posted by Justin

I think doing what you describe is actually quite complex -- a binary compare of the files is preferable IMO, since a) obviously different files will be determined quickly, and b) exactly the same files will still avoid a copy.

Surely not?

https://msdn.microsoft.com/en-us/lib...8VS.85%29.aspx

A final path is the path that is returned when a path is fully resolved. For example, for a symbolic link named "C:\tmp\mydir" that points to "D:\yourdir", the final path would be "D:\yourdir".

Just use that to translate the saved dir path when checking. Should be a few lines of code? At the very least, it could be used as an first choice check before binary compare. Of course, I'm assuming implementation is rather straightforward.

[Justin]

Hmm yeah maybe not too bad, lemme look more.

[Airal]

Originally Posted by Justin

Hmm yeah maybe not too bad, lemme look more.

Thanks. I think it should be relatively easy and there are several ways(win32, junction.exe, etc...). It's not a priority though and it's probably a rather rare issue. I'd settle for the binary comparison as a solution too

[Justin]

Originally Posted by Airal

Thanks. I think it should be relatively easy and there are several ways(win32, junction.exe, etc...). It's not a priority though and it's probably a rather rare issue. I'd settle for the binary comparison as a solution too

This is REAPER, so you'll get... both!

[Airal]

Originally Posted by Justin

This is REAPER, so you'll get... both!

but what if I don't want both?!?!

Thanks man! Your awesome! I wish businesses(governments, people in general, etc) were run by people more like you! The world would be a better place! (I'm not sucking up, just stating the facts )

[lachrimae]

Next time I see a troll I'm pointing them to this thread...

[mschnell]

Originally Posted by Airal

It should be quite easy to get the junction target and compare it to the saved path target.

An application never should "implicitly" look at such hidden properties of any files. This is reserved for OS-internals and OS-tools.

-Michael

[kenz]

Originally Posted by mschnell

An application never should "implicitly" look at such hidden properties of any files. This is reserved for OS-internals and OS-tools.

-Michael

I agree, it should not be on by default definitely...

[Dstruct]

FIXED (5.20pre14)

[Justin]

Originally Posted by kenz

I agree, it should not be on by default definitely...

Why not? it's only used for the limited case of "is this file effectively already there?"

[heda]

Originally Posted by Justin

This is REAPER, so you'll get... both!

Thank you!