user can't delete old events

[n8fr8]

when upgrading from Play to alpha/dev, user can only swipe away events created with new app, not the older ones.

[deviantollam]

i discovered a bit more about this on my devices.

it seems that it may be related to moving/deleting of the JPG and MP4 files in the save directory. presumably, something in Haven's "delete this log entry" process has a step like "go to directory where the files are saved and delete them" but if Haven fails to find said files (because they're already moved/deleted/renamed) then the log clearing process halts/errors right there and the logs are not actually removed.

Fun Fact: in the GUI they appear removed and do disappear, but if you exit and re-open the app, the log files show up again. no way to delete them permanently besides full "Clear Data" from the Android app (and lose all settings in the process)

[deviantollam]

can confirm this is still the case in 0.2.0-beta4

if i delete old files in the /phoneypot directory (or whatever other directory is configured) then the log entries in Haven become un-deletelable.

like, you can clear them by swiping or by "Remove all logs" from the "more" menu dots at the upper right... but exiting and coming back into the app has them re-appear.

on another note... i like that we're seeing the entries in /phoneypot with their own sub-folders. that's awesome! however, if someone chooses to swipe away old events (or use the "Remove all logs" command) then the JPGs and MP4 files and such are deleted but not the sub-folders themselves. is this a huge issue? no. but it adds file system clutter and (more importantly) leaves behind evidence of when the app was running... evidence that could potentially compromise someone. if a user tries to remove some or all events, then best case scenario would be all details of said events (including the YYYY-MM-DD_HHMMSS subfolders) would be deleted.

[fat-tire]

Heyo-- I was having this issue too trying to remove logs and getting the remove to stick. The issue was related to the Event subclass of SugarRecord getting a NullPointerExcetion in the delete() method. I fixed it from crashing (but not from the underlying problem) by catching the exception around line 36-34 of Event.java.

I thought I'd start with a fresh database, so uninstall and reinstalled. But now I'm seeing this (it crashes if I trigger an event):

09-24 22:58:47.067 21446 21446 D org.havenapp.main.ListActivity: android.database.sqlite.SQLiteException: no such table: EVENT (code 1): , while compiling: SELECT * FROM EVENT ORDER BY id DESC

I dunno if this is related to the previous issue, but it also seems to be connected to SugarRecord and maybe com.github.satyan:sugar too?

Incidentally, I should mention I'm almost finished doing a huge update for AS 3.3 & Android P library/build tools/etc (updating all libraries, switching to androidx and support libraries and themes, and a lot more) ... everything was working but now this is catching me up.

@deviantollam is this a reproducible issue for you too? If you uninstall/reinstall do you see this missing TABLE issue in the log?

If this is something unreleated to the big code update I'm doing, it would be good to know. I can take a look at fixing directly then...

[fat-tire]

Update: The non-created EVENT table bug went away when I added:

        SchemaGenerator schemaGenerator = new SchemaGenerator(this);
        schemaGenerator.createDatabase(new SugarDb(this).getDB());

to HavenApp.java. Thanks to this bug for finding the solution.

Now the logs do seem to be deleted. The only thing I'm noticing is that the list doesn't get updated immediately.. it's only when I quit and restore that the list disappears.. Maybe the RecyclerView or whatever needs to be invalidated. I can look into it but the fix above I'll include in my PR in the next day or so.

[fat-tire]

One more note then I'm done--

I found/fixed another crasher in EventActivity.deleteEventTrigger() when eventTrigger is null. This happened when I went into the Log and deleted individual events in the log. Sometimes it gets recognized in the UI and sometimes it doesn't. Somehow the list items need to get refreshed when items are removed.

I'm pretty sure this is all unrelated to what I've been doing. So tomorrow hopefully I'll be able to push what I've done so far as far as bigger updates elsewhere and this can be treated as its own issue....

[deviantollam]

related to my most recent comment above... i am still seeing lingering JPGs sometimes in these folders even after "remove all logs" action.

so we have a few distinct matters:

1. "Remove all logs" or swiping away individual logs still leaves the folders behind, even if they are empty

2. sometimes even a few files will remain inside those folders, actually

3. if a user deletes these folder or files manually (before attempting to remove them in Haven) then it becomes impossible to clear them from Haven

... ultimately, a great solution would be to have "Remove All Logs" erase 100% of the contents of that directory, along with deletion of all of the internal journaling.

[fat-tire]

Places to look:

EventActivity.java -- handles swipe to delete by calling deleteEventTrigger() which has a weird thing where first it deletes the trigger record, then the path of the eventtrigger 3 seconds later. eventTrigger.delete() deletes the record from the databaseand is a method inherited from the library super class SugarRecord.java.

Event.java -- notice that if either the file OR the database fails to delete, the whole operation seems to stop.

What's up with this 3 second delay deleting the path?

This was added by @n8fr8 -- so maybe he could add some clarity and/or clean this up a bit? And if you do, @n8fr8 , maybe you could take a look at my path changes at #351 to make sure it will all merge together?

Cheers!

[archie94]

Maybe because we provide an Undo option after this delete operation by the user.

So we are removing this runnable on Undo and hence not removing the files from disk. If the user does not decide to undo the delete operation, we delete the files.

While making #307 I was thinking of periodic cleanup of phoneypot storage rather than immediate remove from disks. We can make this duration configurable by the user. Please let me know what you think of this approach.

[fat-tire]

Hmm. Yeah just thinking about it I think if this is all going to be switched to Room I'm going to leave it alone :) Hope those changes get accepted soon!

[n8fr8]

The 3 second delay was to allow for the UNDO option. Essentially removing the event from the UI, but not the actual data structure.

I will start reconsidering #307 again!

[n8fr8]

This should all be resolved as of the 0.2.0 beta 4 & 5 release, but we'll do a round of testing to confirm.