[Geany-devel] Safe file saving - permissions issue

Lex Trotman elextr at xxxxx
Sat May 15 12:02:09 UTC 2010


On 15 May 2010 17:34, Lex Trotman <elextr at gmail.com> wrote:

>
>
> On 15 May 2010 14:40, Jon Senior <jon at restlesslemon.co.uk> wrote:
>
>> On Sat, 15 May 2010 14:10:06 +1000
>> Lex Trotman <elextr at gmail.com> wrote:
>> > Since it doesn't know the status of the directory the file was in or
>> > even the whole filesystem, and finding out could cause long delays as
>> > things time out, it is reasonable to ask the user where it is safe to
>> > save the file.
>>
>> I agree. It is more than reasonable, it is to be praised. Better to
>> harass the user a little than to risk losing data.
>>
>> > When a file of the same name re-appears the application can't know if
>> > it is intended to be the same object, so it has to ask the user.
>>
>> Even after a reload. Here's the sequence of events (and this doesn't
>> require a network drive to simulate)
>>
>> > touch foo.bar
>> > geany foo.bar (assumes an existing session)
>> [Edit file in geany and save using ctrl-s]
>> > mv foo.bar bar.foo
>> [Return to geany, you will be prompted that the file can no longer be
>> found and offered a chance to save it. Choose cancel leaving the file
>> open but marked as dirty]
>> > mv bar.foo foo.bar
>> [Return to geany and choose Reload. You will be asked to confirm and
>> then the file is reloaded and it is no longer marked as dirty. Make a
>> change and save with ctrl-s. You will now be presented with a "Save
>> file" dialog]
>>
>>
> I misunderstood, I thought you had said reloading stopped it showing a save
> dialog.  I agree its superfluous if you have reloaded, and as I said I think
> you should be able to tell Geany that its superfluous even if you didn't
> reload.
>
>
>> This is, I feel, broken logic. The file was marked as dirty but has
>> been reloaded from disk. A file reloaded from disk should be no
>> different from a file freshly loaded for the first time. This does not
>> occur if the file is not moved temporarily. By choosing to reload, the
>> user has already resynchronised the geany buffer with the file and thus
>> re-established the link between the buffer and the file. This final
>> prompt is (in my opinion) superfluous.
>>
>> Were it not for the painfully long opening time of the save dialog when
>> dealing with a large networked directory of files, it would be a minor
>> inconvenience, but while waiting for the dialog to open, you have time
>> on your hands to think about this stuff! :-)
>>
>>
> Heh heh, can't have users thinking now can we...
>
>
>> I don't wish to be critical. This is, frankly, my only issue with geany
>> (I'd love it if it could convert R to optimised C, but I don't think
>> that fits into the description of a lightweight editor!)
>
>
> Sounds more like the job description of a compiler :-)  but Geany can run
> one of those for you if you can find one :-)
>
>
>> . I know that
>> I'll not have the time to track this down in the source for a while, so
>> I'm putting it out there. I'm happy to submit a proper bug report if
>> requested.
>>
>>
> I'll have a look at the logic and how easy it is to change if no one beats
> me to it in the next few days.
>
> Cheers
> Lex
>

This seems to be because when a document disappears the real path is cleared
but when it is reloaded the real path is not set again.  I'm not sure about
side effects so I am asking Enrico or Nick, in document_open_file_full can
the setptr( doc->real_path  be moved outside the if (! reload ) safely?

Cheers
Lex




>
>
>>  Jon
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100515/0d189b37/attachment.html>


More information about the Devel mailing list