Use executable path as plugin path

[jvff]

Checklist for a PR:

• Describe the change in CHANGELOG.md. Only applicable if the change has any impact for a user.

---

This change is 

[pronebird]

Review status: 0 of 1 files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

            .parent()
            .map(Path::to_path_buf)
            .ok_or(ErrorKind::ExecutableHasNoParentDir.into())

I am a little bit confused about that error. How's it possible that executable has no parent directory?

I can only see that happen if it's running from memory location but then current_exe() would fail anyway.

Thoughts?

---

Comments from Reviewable

[faern]

Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

---

talpid-core/src/tunnel/mod.rs, line 215 at r1 (raw file):

    fn get_executable_dir() -> Result<PathBuf> {
        let exe_path = env::current_exe().chain_err(|| ErrorKind::ExecutablePathInaccessible)?;

Regarding error handling. I feel it's easy to have an explosion of errors that can virtually never happen. If you look at get_resource_dir() in main.rs do you think the approach we took there has a problem with it? If any error happens along the way we just default to the . path.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

            .parent()
            .map(Path::to_path_buf)
            .ok_or(ErrorKind::ExecutableHasNoParentDir.into())

Strictly according to the types, this error can happen. But can it happen in practice? If the exe_path is a file (it should always be?) then it must have a parent, all files have a parent. The only path that return None on parent() should be / right?

Which means it should be fairly safe to either just unwrap() here, or to fallback to the fallback stated above.

---

Comments from Reviewable

[faern]

Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

I am a little bit confused about that error. How's it possible that executable has no parent directory?

I can only see that happen if it's running from memory location but then current_exe() would fail anyway.

Thoughts?

What does "running from memory location" mean?

---

Comments from Reviewable

[faern]

Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions, some commit checks broke.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

Strictly according to the types, this error can happen. But can it happen in practice? If the exe_path is a file (it should always be?) then it must have a parent, all files have a parent. The only path that return None on parent() should be / right?

Which means it should be fairly safe to either just unwrap() here, or to fallback to the fallback stated above.

Which is why we use pop() instead of parent() over there, since it does not have a failure really, it just stays the same path if it does not have one.

---

Comments from Reviewable

[pronebird]

Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions, some commit checks broke.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

What does "running from memory location" mean?

You can google "launching exe from a memory buffer"

---

Comments from Reviewable

[pronebird]

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks broke.

---

Comments from Reviewable

[jvff]

The Travis CI build failed, but it was due to a compiler bug (rust-lang/rust#48336).

---

Review status: 0 of 1 files reviewed at latest revision, 3 unresolved discussions.

---

talpid-core/src/tunnel/mod.rs, line 215 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

Regarding error handling. I feel it's easy to have an explosion of errors that can virtually never happen. If you look at get_resource_dir() in main.rs do you think the approach we took there has a problem with it? If any error happens along the way we just default to the . path.

Agreed. I removed both errors and used the same approach as in get_resource_dir(). Thanks!

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

Which is why we use pop() instead of parent() over there, since it does not have a failure really, it just stays the same path if it does not have one.

Removed as well, since it should never happen.

---

Comments from Reviewable

[pronebird]

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

---

Comments from Reviewable

[pronebird]

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

---

talpid-core/src/tunnel/mod.rs, line 220 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

You can google "launching exe from a memory buffer"

This piece has been removed so I marked this thread as satisfied.

---

Comments from Reviewable

[faern]

---

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[jvff]

Should this change be described in the changelog? From my understanding this is mostly a developer visible feature, correct?

---

Review status: 1 of 2 files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[faern]

It might also be noticed by power users. And it is a change in functionality. But I agree it could be classified as slightly borderline. I like the part you added, it's good.

---

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[mvd-ows]

Reviewed 1 of 1 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable

[pronebird]

Reviewed 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable