[Geany-devel] Overwriting a link on save as
elextr at xxxxx
Wed Mar 2 01:50:27 UTC 2011
On 2 March 2011 12:26, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> Le 02/03/2011 01:59, Lex Trotman a écrit :
>> On 2 March 2011 10:57, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
>>> Hi all,
>>> A user (yecril71pl) on #geany reported that saving as a file with the
>>> name of a symbolic link correctly ask for replacing but will try to
>>> modify the file at the location pointed by the link rather than
>>> replacing the link by a new file. This is IMHO at least not expected,
>>> and may be problematic if e.g. the target of that link isn't writable,
>>> since the write will fail (if using unsafe file saving).
>> Hi Colomban,
>> It does the same with hard linked files, ie it modifies the file
>> rather than replacing it, and so changes the file for all the links,
>> again probably not what was expected. So I think "save as" should
>> always delete the file (if it exists) before saving, not just on
> Right, good point.
> However removing the file have drawbacks, such as we might not be able
> to create it back if e.g. we don't have write permissions on the parent
> directory but only on that particular file -- though, AFAIK you can't
> remove a file in a directory you can't write to, so it isn't a problem.
> OTOH maybe it's anyway not a real problem to lose the file upon wired
> failure when use_safe_file_saving is false?
Its ALWAYS a problem to lose a file you don't expect to.
> Maybe the best fix would be to use g_file_set_contents() (aka safe file
> saving currently) when saving as? So we don't lose the original if we
> haven't the new one...
but we then assume that safe file saving is
> implemented as temp file writing and rename.
Well its documented as doing that, so we are not depending on an
undocumented implementation feature.
> It probably depends on whether we can assume or not that if we
> successfully removed the original file we'll be able to create the new one.
> Again, thoughts?
g_file_set_contents is documented as behaving the way we want with
respect to links so that sounds a good way to go instead of deleting
the old file and hoping we can create the new one. Of course on
Windows g_file_set_contents has its own set of problems, so
technically we should do something else when writing to a windows file
(eg via samba) but I don't know how you tell so ignore for now?
More information about the Devel