ssymlinkdirs and Junctions

[jporkkahtc]

Can +ssymlinkdirs be made to also recognize junctions?

[Clark]

We will see what can be done for junctions after v21 is out. I'm not sure if this is possible or not.

[jporkkahtc]

On unix-y systems do you make use of the iNode # to determine if you have duplicate copies of the file thru different paths?


On windows, can you make use of nFileIndexHigh+nFileIndexLow+dwVolumeSerialNumber?


These won't tell you if path of the path is a link of some sort, but at least you would know if two paths point to the same file.

[Clark]

I think we do use the iNode and the dev number to avoid infinite recursion. We also fully resolve Unix symbolic links like we do on Windows.

I haven't studied Junctions enough to know what we can and can't do. If they can be resolved efficiently, that would be best.

[Clark]

I attempted Junction support for RC 3. Give it a try. If you turn on symlink directory support, it turns on the Junction support as well. It works identically to the implementation for Windows symlinks.

[jporkkahtc]

Cool - works!


File History keeps duplicates.
e C:\Users\joe\JUNCTION_to_Folder\foo.txt
e C:\Users\joe\Folder\foo.txt


Slick recognizes foo.txt is the same file, but keeps the buffer name as the first used to load the file.
It then keep *both* entries in the file open history.

[Clark]

This isn't fixable without robbing Peter to pay Paul (fixing it for you and breaking it for someone else).

You would think it would be fine to resolve the symlinks when doing the matching (trivial to do). Nope. Can't do that because there are customers that have build tools which only work on the unresolved absolute name. There's no way for us to know which one is the one they really want us to use. When SlickEdit parses in the buffer name, it's always uses the unresolved absolute filename. When we've broken this, we get notified pretty quickly.

When opening a file, it isn't safe to open a file twice. If you specified the wrong path, you have to close it if you want to correct the buffer name. There's no other option for that case.