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
