I have created an Issue ( https://pharo.fogbugz.com/f/cases/21708/Epicea-should-not-offer-to-recover-changes-if-the-ombu-file-does-not-exists ) to follow the conversation and to notify Martín and listen to his opinion.
Cheers, Pablo On Sun, Apr 15, 2018 at 7:02 AM, Ben Coman <b...@openinworld.com> wrote: > 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 > -- Pablo Tesone. teso...@gmail.com
