> > On Sat, Apr 14, 2018 at 5:56 PM, Hilaire <hila...@drgeo.eu> wrote: > >> Replying to myself for the record, these two lines seem to inactivate >> Epicea >> >> "Inactivate Epicea" >> EpSettings monitorEnabled: false. >> EpSettings lostEventsDetectorEnabled: false. >> >> >> Now, there is still likely an issue I don't understand > >
On 15 April 2018 at 00:32, teso...@gmail.com <teso...@gmail.com> wrote: > Hi, > I have been checking this problem and the message is shown because is > trying to find the ombu file for the current session. > Usually what it does is comparing the file with the recorded size and > timestamp in the image to check that the file has no new changes. > If the file is newer or larger than the previous info of the image, the > recover message appears. > > I think there is a bug here, although I am not sure, I think that MartÃn > has to help to understand it. > Because in the current implementation if the file does not exists it > produces the recovery message. > Even though it can show that there are changes, if there is no file with > them I think is quite difficult to recover them. > > This behaviour is not happening in the machine where the image is built, > because the file exists in the disk. They are stored in the pharo-local > directory. > > Cheers, > Pablo > I didn't have a chance to check for repeat-ability, but yesterday I saved-quit and Image-A, then in PharoLauncher did a Copy of Image-A to image-B, then opening Image-B got a question about Recovery that I didn't expect or want. cheers -ben
