When trying out symbolic links on windows i noticed links breakage when geany saves files accessed through such a link.
Steps to reproduce:
1) Prepare link: ```powershell $myDesktop = "$($env:USERPROFILE)\Desktop" New-Item -path "$myDesktop\target.txt" New-Item -path "$myDesktop\symbolic.txt" -ItemType SymbolicLink -Value "$myDesktop\target.txt" ```
Note: Last statement needs admin privileges (at least until creators update or adapting a policy setting).
2. Use geany to edit ``$myDesktop\symbolic.txt`` and save
Expected behaviour: Content of ``$myDesktop\target.txt`` reflecting latest edit while ``$myDesktop\symbolic.txt`` still pointing to that file.
Observed behavior: ``$myDesktop\target.txt`` is never touched by the edit. ``$myDesktop\symbolic.txt`` is now a regular file.
This was observed using version 1.30.1
Correct.
Geany writes the file to the path it is given, it has no way to know you did not intend it to overwrite the link. It is the same behaviour on linux (and I presume OSX).
If it is intended behaviour .. no problem.
The only thing that put me off (and the reason for this report) is that on my linux system geany (using the default configuration) honours symbolic links (those created by ``ln -s``), which partly contradicts your statement.
The only thing that put me off (and the reason for this report) is that on my linux system geany (using the default configuration) honours symbolic links (those created by ln -s), which partly contradicts your statement.
Ahh, on more consideration it will depend on which saving method you use:
1. if neither atomic or GIO saving is selected Geany opens and writes to the original file, that should honor the link,
2. if you use atomic file saving it creates a new file and renames it over the specified path, that will replace the link. This is what my system was set to when I tested yesterday.
3. if you use GIO file saving it will do the same as 2 unless there is a problem in which case it will do 1, so its anybodys guess, but on most normal local files it will replace the link. This is the default option.
Ah yes those options. It somehow sparked an interest here so I decided to test behaviour (and increase my understanding) perhaps it is of use for others as well:
- | Gio backup | Use atomic | Use Gio | win10 | Ubuntu 17.04 | Notes -- | -- | -- | -- | -- | -- | -- Default | n | n | y | new file | preserve | test1 | y | n | y | new file [1] | preserve [2] | test2 | y | y | y | new file | new file | Should act as test7 test3 | n | y | y | new file | new file | Should act as test7 test4 | n | n | n | preserve | preserve | Point 1 test5 | y | n | n | preserve | preserve | Should act as test4 test6 | y | y | n | new file | new file | Should act as test7 test7 | n | y | n | new file | new file | Point 2
The *Should act as* comments are based on my understanding of the wiki information. The *Point* comments refer to expected behaviour from your points
The 1st observation I draw from this is that gio (it is a gtk library corrrect?) behaves differently on windows and linux. The 2nd observation is that my linux box does not behave as in your 3rd comment. If I understand that one correct the default behaviour should create a new file. However (luckily for me) it honours the link.
[1] link is renamed to link~ (but preserved as symbolic link) [2] link~ is a new file with old contents as described in wiki
note: Under windows I also ran tests with geany as admin to rule out any permission problems in (re)creating symbolic links. The results from those test were identical to the normal user, hence I omitted those.
[1] link is renamed to link~ (but preserved as symbolic link) [2] link~ is a new file with old contents as described in wiki
I didn't think Geany saved backups with `~`? Maybe you have a plugin like Save Actions enabled or something?
@R1dO nice review
The 1st observation I draw from this is that gio (it is a gtk library corrrect?) behaves differently on windows and linux.
GIO is of the Glib/GTK family yes, and indeed it would appear that it does not understand Windows links. The only way to know what it does is to read the source, and of course that can have changed since I looked (see 2013 date on wiki entry).
The 2nd observation is that my linux box does not behave as in your 3rd comment. If I understand that one correct the default behaviour should create a new file. However (luckily for me) it honours the link.
In fact it is because it behaves as in my point 3 in the first two rows (the only two using GIO) that it preserves the link, it falls back to writing over the old file when something goes wrong with creating and renaming the new file, including not being able to copy the old files metadata, like permissions and ownership. Are you sure your permissions and umask allow it to set those? But possibly it also specifically checks for and preserves links.
@codebrainz GIO makes the `file~` backups if its called with the boolean parameter set, see the left hand option in the table.
Of course this only works if GIO is used, so only in that one row.
Thank you
@codebrainz I did not have that plugin enabled. Before I did those tests the existing ``.config/geany`` folder was moved out of the way so geany could recreate the default settings.
@elextr I totally misinterpreted your 3rd point then. To me it came across that gio would first use the atomic routine (even when not selected) and only try gio if the atomic is not able to recreate metadata. As for the permissions (linux only, all i get from my limited windows Powershell knowledge is *Full Access*): * The umask on the directory used during the tests was: ``0002``. * Permissions on the link are: ``Access: (0777/lrwxrwxrwx)`` * Permissions on the target are ``Access: (0664/-rw-rw-r--)`` * Permissions on the backup file are ``Access: (0664/-rw-rw-r--)``
Derived from the comments in the Glib library I do believe that gio checks for and preserves the link. The writing routine ``[geany]\documents.c::write_data_to_disk()`` for atomic writes calls ``[glib]\ gfileutils.c::g_file_set_contents()`` this function warns about not preserving symlinks in the description. That same routine for gio writes calls ``[glib]\gfile.c::g_file_replace_contents()`` this function (and callees) do not warn about this. Hence my (weak) conclusion that by default gio will preserve symlinks.
To me it came across that gio would first use the atomic routine (even when not selected) and only try gio if the atomic is not able to recreate metadata.
The `g_file_replace_contents()` is a GIO function, and (when I read its source) it creates a new file, tries to copy metadata from the existing file, if that succeeds it writes the new data and does the rename over the old file, if any of the above fails, it copies the old file to a backup, truncates the old file and writes the new data to it, thus preserving metadata and links. So it does use the atomic method if it can, but not by calling `g_file_set_contents()` and note its all in GIO, not something Geany does.
I don't remember and didn't record what it does with links when things succeed, and as I said above it may have changed in the last four years. If you checked its source and it has comments in the code that say it handles links then thats great, but as its not documented behaviour don't depend on it.
Unfortunately my limited capability of understanding the glib code could only lead to noting the absence of comments regarding link preserving. Which could also mean I wasn't looking that well ;-)
... but as its not documented behaviour don't depend on it.
A wise statement that I will have to keep in mind.
Thank you for spending some time clarifying this behaviour.
For my curiosity, what does the commands in the first post exactly do? It looks like PowerShell however, they don't work out of the box in a Windows 7 PowerShell.
Is it just creating a shortcut as it is done with the Windows GUI methods? If so, they should be handled by Geany by resolving the shortcut to its target before opening anything and then the target file is opened directly in Geany.
Though your report sounds more like there is something like real symbolic links on newer Windows versions?
You are correct on all accounts (PowerShell, symbolic link and this report not being about shortcut files).
The commands in the 1st post will create a test scenario with an (empty) regular file and a symbolic link to that file on your desktop.
I'm not sure when symlinks were exactly introduced in the Windows ecosystem and/or what the required steps are to activate them on older windows builds. I do know however that the next update will probably start increasing their popularity for using them under windows 10 by not requiring admin credentials after activating that feature.
I'm not sure when symlinks were exactly introduced in the Windows ecosystem
From [the docs](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).a...):
Symbolic links are available in NTFS starting with Windows Vista.
Ah yes .. I must have overlooked that info. It was even mentioned in the windows developer blog [post](https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#Uv79W...) that sparked my fiddling around behaviour. It is basically about the change from *admin elevation required* into *need to enable "developer mode"* or *add a certain flag when calling the c++ API* in order to use the symbolic links.
@eht16 The commands used in my 1st post are based on recently introduced "Windows Management Framework" PowerShell CmdLets described in the [msdn docs](https://msdn.microsoft.com/en-us/powershell/wmf/5.0/feedback_symbolic). Those cmdLets could work on Windows 7 but require some extra package installation (see *installation details* section on that webpage). The command ``mklink`` should work in your situation.
Hmm, `mklink` doesn't exist as command on my system, probably I don't have the "developer mode" enabled, no idea what this is and I think I don't want it to activate on the machine where I create the release binaries.
Anyway, since this issue seems resolved as intended behavior (if I got the comments above correctly), it doesn't matter much to me.
I assume you tried under PowerShell. Apparently buildins from ``cmd.exe`` (the original windows shell) are not available by default in PowerShell. In your case there are 2 options (sorry for the incomplete reference in my last post): * run ``mklink`` from a normal (``cmd.exe``) shell * run ``cmd \c mklink`` from a PowerShell
Developer mode is a windows 10 thingie so you shouldn't worry about it. This report shouldn't have any impact on creating release builds (unless you are planning to introduce symlinks in the code base).
At the moment the impact from this report is probably pretty low. Depending whether or not symlink usage under windows starts snowballing (due to increased usage of certain package managers and symlink heavy git repositories for instance) it could become a usability issue.
One other note. When setting up to provide a 3rd column to show behaviour when using shortcut files (*.lnk) I noted that the link is dereferenced upon opening showing the target. Although it prevents the problem stated in this report it might add to the confusion (why do .lnk files dereference and symlinks not). It could off course also be intended behaviour, but for completeness I wanted to include this.
github-comments@lists.geany.org