"...has been modified outside of Leo. Overwrite this file?

[Ville M. Vainio]

I get this error way too often compared to the amount of cases when
it's actually useful (I think Leo uses wrong logic here, but didn't
check):

/home/ville/.leo/workbook.leo
has been modified outside of Leo. Overwrite this file?

The problem is that once you get it too often, it becomes meaningless
and doesn't really help to avoid dangerous modifications when you
actually *have* modified the file. Am I alone with this problem?

I'm on Ubuntu Maverick.

[Edward K. Ream]

Thanks for bringing thoughts that have not quite become conscious into
full view.

Feel free to file a bug report.

Edward

[HansBKK]

Sorry for the zombie resurrection, but apparently nothing ever logged to the tracker on this?


I'm not worrying about it much for those filesystem trees under version control, but I imagine this could be panic-inducing for a newbie.

If it's helpful I'll try to isolate what's happening in my workflow to trigger this, but it's not **that** frequent, and I can't think of anything out of the ordinary so far.

The element that concerns me is that I'm getting this message even when the file contents has not actually been modified, as confirmed by the log pane.

Perhaps the file comparison function(s) used to generate the "unchanged" log messages could be run before the one that pops up the warning message? I suspect it's the latter is triggered by attribute changes or something rather than actual content checking.

Sheer speculation on my part of course. . .

[Edward K. Ream]

On Tue, Dec 27, 2011 at 8:47 PM, HansBKK <han...@gmail.com> wrote:
> Sorry for the zombie resurrection, but apparently nothing ever logged to the
> tracker on this?

I believe this bug has been fixed. Don't know exactly when.

Edward

[HansBKK]

 I'm running build 4899 11-12-22, and have been getting the pop-up immediately followed by an unchanged log line wrt to that file.

But as I said, it's not frequent enough, and I don't know how to make it happen, so ignore for the moment, I'll try to come back with a minimal test case next time it comes up.

Hmm, maybe only line endings getting converted?

[Edward K. Ream]

On Fri, Dec 30, 2011 at 4:09 PM, HansBKK <han...@gmail.com> wrote:

>  I'm running build 4899 11-12-22, and have been getting the pop-up
> immediately followed by an unchanged log line wrt to that file.
>
> But as I said, it's not frequent enough, and I don't know how to make it
> happen, so ignore for the moment, I'll try to come back with a minimal test
> case next time it comes up.

It comes up from time to time for me, but I have not recently seen it
come up *erroneously*. That is, every time it appears it is a
legitimate message. Besides the obvious way for this to happen (the
file has actually been changed in an external editor), it can also
happen as the result of a bzr revert.

Edward

[Terry Brown]

Steps to reproduce:

Create a node "@edit ~/Desktop/del.txt" assuming del.txt does not exist

type something in the body

Ctrl-S save outline, log reports creating ~/Desktop/del.txt

Edit text in body

Ctrl-S save outline, pop-up pops-up erroneously.

Cheers -Terry

[Edward K. Ream]

On Mon, Jan 9, 2012 at 9:15 AM, Terry Brown <terry_...@yahoo.com> wrote:

> Steps to reproduce:

Excellent. I'll fix this today or tonight.

The various flavors of @<file> nodes are maddeningly similar, yet each
different enough to make refactoring difficult. This may be an
@edit-only problem. Or not.

EKR

[Edward K. Ream]

On Jan 9, 12:29 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

> Excellent.  I'll fix this today or tonight.

Done at rev 4919. Here is the checkin log:

QQQ
Fixed erroneous "file changed" message.

This was a one-line addition to at.replaceTargetFileIfDifferent.

I did *not* add a new unit test because I did not want to save
the .leo file in the middle of unit tests.
QQQ

I considered various unit tests for @edit or
at.replaceTargetFileIfDifferent, but they might do more harm than
good. For the moment, I'm willing to go without a safety net. I'll
consider adding a unit test if further problems arise.

This is an example of a more general testing problem: unit tests can,
and sometimes do, alter unitTest.leo. Thus, I would prefer not to
have any unit tests save unitTest.leo.

Edward

[Kent Tenney]

I see it with @auto.

Thanks,
Kent

 Or not.
>
> EKR
>
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>

[Edward K. Ream]

On Mon, Jan 9, 2012 at 3:09 PM, Kent Tenney <kte...@gmail.com> wrote:

> I see it with @auto.

Did your email cross in the ether? I don't see the problem with rev 4919.

Edward

[Kent Tenney]

Sorry for the noise, 4919 looks good.

>
> Edward