[Github-comments] [geany/geany] Opening symlink-ish files (#1567)

[Ben Wiederhake]

Symlinks, directories, and the magical `..` entry have never played well together.
However, tools usually are consistent in the interpretation of `..` in this context:
Either it is the parent of the symlink folder, or the parent of the target folder.

In geany, however, it just causes strange and subtle errors, which is never a good thing.

Here's an example so I have things to talk about.
Note that I write `~` only for succinctness.  Geany correctly uses only the fully expanded paths.

```
# Setup
~/test$ mkdir -p realdir/subdir
~/test$ ln -s realdir/subdir/ symlinksubdir
~/test$ echo "Some text" > realdir/existingfile.txt
~/test$ echo "Different words" > toplevelfile.txt
~/test$ cd realdir/subdir/

# Demonstrate behavior in plain folders
~/test/realdir/subdir$ ls ..
existingfile.txt  subdir
~/test/realdir/subdir$ geany ../newfile.txt  # (1) Opens a tab for a not-yet-existing file ~/test/realdir/newfile.txt
~/test/realdir/subdir$ geany ../existingfile.txt  # (2) Opens the existing file
~/test/realdir/subdir$ cd ../../symlinksubdir

# Demonstrate behavior in symlink folders
~/test/symlinksubdir$ ls ..  # The entry '..' points to '~/test/realdir', not '~/test'
existingfile.txt  subdir
~/test/symlinksubdir$ touch ../toplevelfile.txt  # Shell expansion sees '..' as pointing to '~/test', not '~/test/realdir'
~/test/symlinksubdir$ geany ../newfile.txt  # (3) Opens a tab for a not-yet-existing file ~/test/newfile.txt
~/test/symlinksubdir$ geany ../existingfile.txt  # (4) Fails when fetching file information (?), refuses to open a new tab.
~/test/symlinksubdir$ geany ../toplevelfile.txt  # (5) Opens a tab for a "not-yet-existing" file ~/test/toplevelfile.txt
```

Expected behavior, flavor "parent of symlink":
- Command 3 opens a tab for a not-yet-existing file `~/test/newfile.txt` (matches actual behavior)
- Command 4 opens a tab for a not-yet-existing file `~/test/existingfile.txt` (differs)
- Command 5 opens a tab for the already existing file `~/test/toplevelfile.txt` (differs)

Expected behavior, flavor "parent of target dir":
- Command 3 opens a tab for a not-yet-existing file `~/test/realdir/newfile.txt` (differs)
- Command 4 opens a tab for the already existing file `~/test/realdir/existingfile.txt` (differs)
- Command 5 opens a tab for a not-yet-existing file `~/test/realdir/toplevelfile.txt` (differs)

Expected behavior, flavor "avoid weirdness":
- Command 3 refuses to resolve `symlinksubdir/..` at all (differs)
- Command 4 refuses to resolve `symlinksubdir/..` at all (matches actual behavior)
- Command 5 refuses to resolve `symlinksubdir/..` at all (differs)

Note that the cases 3 and 4 "only" cause confusion about where a file is or will end up.
In case 5, a user might attempt to write something into a file (i.e., add to a TODO-style list),
find it empty on the current machine, and save it – and thus, without any warning, overwrite the existing file.
Data loss.  Sad panda.

I have no idea how the "Open File" dialog stuff relates to this.  The bugtracker apparently knows nothing like this.

If I were to touch the code that deals with the file name resolution and handling,
which flavor would you prefer for a PR?  Parent-of-symlink or parent-of-target?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1567
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20170731/747a16c0/attachment.html>