What steps will reproduce the problem?

All mail is received as header only.

Select mail header results in "Downloading..." and sometimes "Connection Error" because of intermittent Verizon service in my service area and slow POP mail server.

What version of K-9 are you using? current version downloaded from "market" 12/08/2009. Sorry, I don't see a build.

Is your email account a POP account or an IMAP account? POP account

Does this problem also occur on the built in 'Email' client? Yes

Please provide any additional information below.

Is it possible to please receive messages in there entirety directly to the HUGE 16Gig SD card? An option to bring in "1)headers only, 2)all the message, 3)all the message plus attachments" would be so grand. Poor Verizon service and slow POP server make checking mail a major chore.

I think this is an important enhancement and should have higher priority. It's the difference between a truly high-class email client and "the rest of the clients". This is a feature that ChatterEmail has, and if you look into the (Palm OS) users of that program, they are all HAPPY (I sure was!!).

K9 would be fantastic if it would automatically download the full message (let it be an option selectable by the user) directly to the SD card. This is important because that way the message downloads in the background, and when we go to look at the message we don't have to stand there waiting to see it. Even better yet, offer encryption for the stored messages (like ChatterEmail does).

Hi,

Recently I was traveling to Korea. I turned on my phone when the plane doors opened and by the time I walked off the aero-bridge k-9 mail had already downloaded 400kbytes of data of the 3G network while I was roaming. That's $8 to my bill.

Having a setting to download headers only while roaming is definitely a life saver....at least to the Wallet. I like the idea of user selectable download types. E.g. Headers only. Emails only, emails and attachments.

When I am not roaming, i wouldn't mind downloading emails only.

Thanks for listening!

Hi there,

I agree that the only thing missing from K-9 Mail is the option to download:

Headers only. Emails only. Emails and attachments.

Also is there a help.txt file for K-9 Mail? I don't understand the folders (1st class, second class)

Thanks, Donovan

In my view, the single biggest problem with Android, and that severely limits K9 too, is that phone has ~250MB of phone storage and ~32,767MB of SD storage, and K9 can only store all my email in one of those locations. Since other apps have the same problem, I can afford about 25MB for K9 - about 1000th of the space free on the SD card; makes me cry :-)

I constantly struggle with running out of space. If I want to sync a few more messages I have to choose which app to uninstall first to make space. I could do soooo much more with K9 if storage could be SD-based. Is there no way this can happen? Does Froyo apps on SD make this possible for K9? (N1 2.2 FRF91)

I guess this could be implemented in Account.java by replacing mLocalStoreUri = "local://localhost/" + context.getDatabasePath(mUuid + ".db"); with something like context.getDatabasePath("/sdcard/" + mUuid + ".db") if the user chooses to store the email on the SD-card-

Care would have to be taken that LocalStore.java line 100 still works. (It expects the first part of the db-path to be the uuid of the account.)

Here is a patch that cleans up LocalStore to make no assumptions about the location of the database.

Here is an UNTESTED patch to store mails on the SD-card. It also adds a missing german translation of another setting.

Marcus,

Thanks for the patches. The "hard part" of using the SD card for mail is actually around:

• handling sd card removal / reinsertion correctly
• handling migration

There's a branch in the svn repo where baolongnt did a bunch of work toward this some months ago. His changes would be a good place to start.

Thanks. I wanted to test where the critical points are by allowing it only on account-creation and letting it run. No migration yet.

BTW, all HTC-phones are least must have their batteries removed to remove the SD-card. But of cause sd-card sharing via USB is an issue.

seems to basically work. I did not test creating an account without SD-card nor removing the SD-card but at least it's an option for people who are not afraid to patch their K9 until a permanent implementation is found.

(A significant # of folks in the US with HTC phones still have T-Mobile G1s with externally acessible SD cards)

But yeah, usb-mount of SD is the exact same problem.

Basically, we need to listen for certain broadcasts from the OS and tell K-9 to stop fetching or to start fetching. It shouldn't be too bad.

FWIW, once we have "suspend when USB is mounted", I would be fine to have "On SD" be selectable as an account is created and then immutable, at least until someone writes migration code.

This patch adds the ability * to store mails+attachments on the SD-card. * to move the storage-location between internal flash and SD-card in account-setup at any time. * the setting to do so is in "incomming server"

TODO: * test this throughoutly!!! I only tested with a hand full of mails and this digs very deep into critical code. * properly suspend and restart db-activity in the LocalStore-class on sd-card removal/reconnection (broadcasts exist for this purpose) * AttachmentProvider is probably fine with simply not finding it's attachments for a while without crashing too badly

this patch includes my patch filterFoldersAndFoldersMenu2.patch http://code.google.com/p/k9mail/issues/detail?id=2099 for issues #2099 and #2098

I tried to write many more comments then the existing code had to make this easy to understand.

changes: * Account.mLocalStoreUri is no longer constant * Account has a new method setUsingSDCard() and isUsingSDCard() * AccountSetupIncomming contains the UI to change this setting * Account has the LocalStore as a LocalStoreMigrationListener * LocalStore does the migration between different pathes * AttachmentProvider properly handles the changed localStoreUris * AttachmentProvider got a note and a back-reference-javadoc in Attachment.java that is makes assumptions about the structure of localStoreUris * thumbnails are still kept on the device in the cache-folder * German and English translations for the new setting are provided

This is great! Will it be on the next release? Thanks!

First it has to be throughoutly tested. Then it's the decission of the maintainer what patches make it into the next relaese.

Comment deleted

You are right... I want to apply the patch but it seems a little bit scary! I am not very familiar with android/java programming.

I cannot create a branch "sdcard" for this due to:

Branch operation for some of selected resources failed. svn: Commit failed (details follow): svn: Entry '/home/marcus/workspace/k9mail' has unexpectedly changed special status

Any idea?

I attached a signed apk-file for anyone willing to test this. (It mail fail, it may eat your local mail but it SHOULD not harm any mail on the IMAP-server.) Please test especially: * attachments * POP3 instead of IMAP * migrating back and forth

This feature is such a big deal that if you told me I could never remove or usb-mount my SD card again I'd still be happy to install it :-)

As for migration, as long as it is an IMAP account I assume we can delete the SD-based account and any cached mail and then create a new account on internal storage and download any synced folders again. That would be perfectly acceptable to me if a need to migrate from SD ever comes up. Sure, its a chore to reconfigure, but not one you'd have to do often.

Migration is more of a issue every time I move to a new Android phone, or once I buy and Android tablet later in the year and what the same K9 configuration there as one my phone. Certainly be nice to be able to export and import account settings in those situations.

Migration is MUCH easier. The LocalStore is capable of just closing the database, moving the files from one folder to another and opening the db again.

Please open another ticket for exporting and importing account-data as this is not related to the sd-card issue here.

Issue 210 has been merged into this issue.

The code is in the branch http://code.google.com/p/k9mail/source/browse/#svn/k9mail/branches/mail-on-sd

it worked perfectly fine the last few days. Some known issues with IMAP popped up but they are unrelated to this patch.

Did anyone else test this?

Unfortunately I dont even come close using it, since during the setup (after typing in email and password and hitting the next button) I always get FCs of process com.fsck.k9

FC?

Forced close

Same here, I get force closed right after entering the account credentials. :l

So, what's the stack-trace? What Android-Version? What kind of account did you create with what settings?

With an IMAP-Server and creating an account on SD and on the phone was no problem.

I created a googlemail.Com imap account, Android version was 2.1. I tried deleting the old data/com. Fsck. K9 directory, as iirc it crashed right off the bat before that. I don't have it installed right now - are their stack traces left on the device I could find to have them posted?

logcat can show you the log and email it. Marcus@Wolschon.biz I'm curious what could have happened.

Tomorrow night I may be able to install exactly that version and test with a gmail imap-account. There are some known IMAP-issues unrelated to our SDcard-patch. Jesse Vincent is working on them.

We'll see what happened soon. thanks for the info.

Scott: Try this onw.

Marcus

Marcus, thanks for working on this! What is the minimum android version required for your apk? I'm on CyanogenMod 4.1.999 which I think corresponds to android 1.6 and when I install your apk it says it can't be installed on "this phone".

With only 26mb of free space and k9 using 19 of that, I really can't continue to use stock k9 with this phone (ADP1).

Marcus: I've tried to install your release, and it does offer a checkbox for storing the mail on the SD card, but when I try to check it I get a popup saying something like "/sdcard/file-with-many-digits-and-letters has / in its name" and then the checkbox is disabled.

Aside from that I don't see any functionality change - so that didn't work out for me. If you can fix that and put out another release, I'd be very happy to test that.

Thanks.

http://developer.android.com/guide/appendix/api-levels.html#filtering

A minimum of Andorid 1.5 is required.

This issue is already fixed in the mail-on-sd -branch at http://code.google.com/p/k9mail/source/browse/#svn/k9mail/branches/mail-on-sd

(am waiting for an answer to my question of how best to implement handling of SD-removal http://groups.google.com/group/k-9-mail/browse_thread/thread/a59eae33356b4dd3 before there will be a new binary.)

Marcus

I uninstalled my old K-9 and the new one installed without an error, but during setup, when I enter my email, type a character in the password field so I can click "Manual setup", then click "Manual setup", it crashes. It also crashes if I click "Next". I've attached a log.

Thanks. The issue in the log is already fixed.

Hi Marcus,

In which location/folder that mail contents are saved in SD card?

Looks like mail is stored in /sdcard/k9

It took me a few hours to get it to compile from source (as it always seems to with changes made over a few months), but the result works on my phone with no apparent problems.

I was getting a compiler error: k9mail-sdcard\src\com\fsck\k9\activity\MessageView.java:83: package com.fsck.k9.web does not exist which I solved by downloading from svn: trunk > src > com > fsck > k9 > web. I then moved the web directory and its java files to k9mail-sdcard\src\com\fsck\k9 and it finally compiled. I've attached the result so others don't have to go through the same pain.

Kanisdragon: thanks for the build, but currently i can't get it to install. I've just upgraded K9 to 3.003 so it probably doesnt let me upgrade because the listed version in your build is earlier. Can you possibly do another build (if you already have the setup) with a version number that can upgrade from 3.003 ( possibly 3.004)?

You can't install/upgrade to another (unofficial) build of K-9 Mail if you have the original K-9 Mail installed. That's because the packages are signed and upgrading is only allowed if the certificates match.

So to try out this build you have to uninstall K-9 Mail (and lose all settings), then install the new package.

I kept experiencing a crash described in issue r2335. Someone posted a link to a fix which I applied and here's the compiled version.

Right, like cketti said, I can't release a compiled version compatible with the official version without the signing key that goes with the official version.

You might be able to preserve your preferences by copying /data/data/com.fsck.k9/databases/preferences_storage and /data/data/com.fsck.k9/shared_prefs somewhere else, uninstalling your version, installing mine, then copying those files back. I've never tried that and am only guessing it will work based on the names of the files. This is also assuming the pref files haven't changed format at all between the two versions, which is probably not a safe assumption since the sdcard setting must have been added... but maybe the sdcard version will know how to add that setting in to the file.

Branch merged from current trunk.

Attached is a build from mail-on-sd signed with the release keys.

This is working really well so far, upgraded perfectly and has freed up lots of much-needed space on the phone. Thanks!

This issue was updated by revision r2342.

Added storage location indirection to handle more than 2 storage, in order to properly handle devices such as HTC Incredible (/emmc & /sdcard) or Samsung Galaxy S (/sdcard & /sdcard/sd) Support for these device is present but not active as I don't have such device to test One should consider using /Android/data/com.fsck.k9/files/ path when storing on SD Card in order to automatically remove K-9 files when uninstalling (Android 2.2+)

I've installed the last debug version by Jessev, and it works better then the previous build - it stores stuff on the sdcard and leaves my phone's memory free for more applications (yay!).

That being said, I've noticed a few odd behaviors that I did not notice in the latest release: 1. It doesn't want to open image attachments (claiming there is no viewer for image/jpeg) and when I try to save an image attachment, K9 crashes. 2. If I go to another application and comes back to K9, it should still be in the same folder I was last looking and show me the messages that were last there - but instead when I go back to K9, it shows the correct folder but there are no messages there at all and it immediately polls the server to download the latest batch of X messages again. This is especially annoying if I download another batch or more, and now I have to do it all over again and the download is a lengthy process.

As it seems, the second part of this issue is beeing dealt with and looks like to work pretty good. But what about the issue regarding header only download? I really think this is a crucial setting/option. Just again i experienced, that the download of the headers worked really fast, but after that i had to wait for a long time K9 downloading the first 1k of my mails. Is this header only thing really such an issue to implement? Additionally it would be great, one would be able to configure header only/email download on a per folder basis. But in the first step only header download would still be enough!

Issue 2284 has been merged into this issue.

I confirm that Jessey's build from comment 45 does not either display any inline images (just a blank spave and icon), nor does it allow you to save any attachment (pressing Save causes to to grey out for a while, but nothing ends up in the downloads folder). It also cannot open them as it just says it cannot find an app to view them, be it jpeg, gif, doc, pdf of whatever.

Going back from reading an email to the list causes the page to blank for a few seconds- not sure why- is this because it has to re-download headers, or just because it is slower to read the storage databases on the SD card perhaps?

If I am reading an email and switch to another app (or just press Home), then return to K9, it goes back to that folder's header list rather than the email itself. I can't actually remember if this is what it did before or not, but it would be nice if it went back to the page it was left at.

This issue was updated by revision r2350.

• Try to be smarter into checking for vendor specific storage by matching against mount points from File.listRoots()
• DB code moved from AttachmentProvider to LocalStore
• Synchronize access to the LocalStore underlying DB so that destructive operation (like migration) have exclusive access using a ReentrantReadWriteLock:
  • DML operations use the non-exclusive read lock
  • DDL operations and DB creation/migration/deletion code use the exclusive write lock ... that should prevent any background thread from failing because DB is migrating

I'm back from my vacation. Good point with the vendor specific storage. I did not think about these.

The attachment-issues sound like my changes to AttachmentProvider did not make it into the second apk-build. SDK "adb logcat" or "aLogCat"-app -output helps to solve such bug-reports.

As for uninstalling, there is no intent the app gets when it is to be uninstalled. So it cannot execute any custom code on uninstall.

Fiouzy: you realize that the DB is closed during migration, so there cannot be a db-lock held while migrating? (Migration happens on a file-level, so the SB cannot be open at that time.)

Still noone has answered about how best to handle the case of receving an intent that the SD-card is being unmounted/returned. That is the one major point missing to finish this and get it out to the people.

The returning to the last folder has absolutely nothing to do with this issue and already has it's own ticket.

Welcome back! DB is indeed closed during migration: if not locking, the push thread could try to insert a new message in DB while it's not back online from migration/recreate attempt and would fail. I think it may apply to the new MessageProvider if a request is made during migration.

You could come to IRC on irc.freenode.net in #k-9 if you want to discuss more.

Please see attached log for the message problem. In the log you can see that I first try to "open" an attachment and get an exception, then I try to "save" an attachment and get another exception.

Regarding the sdcard unounting issue - if my feedback as a user is relevant then I'll just note that as far as I'm concerned, if the sdcard is being unmounted, or not mounted when k9 starts, the program can just note that that the sdcard is unmounted and have all accounts that use sdcard storage be disabled and inaccessible (including for poll or push mail check). If that is difficult to do, then as a temporary solution for releasing the sdcard storage functionality then even stopping the program and exiting when sdcard is unmounted is an acceptable solution.

Cheers.

The relevant log-lines are:

E/k9 (13047): android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.intent.action.VIEW dat=content://com.fsck.k9.attachmentprovider/%2Fmnt%2Fsdcard%2Fk9%2F478f550e-f4ae-4c20-8736-9611e9c90bcb.db/308/RAW flg=0x1 }

E/AndroidRuntime(13047): java.lang.IllegalArgumentException: File /mnt/sdcard/k9/478f550e-f4ae-4c20-8736-9611e9c90bcb.db_att contains a path separator E/AndroidRuntime(13047): at com.fsck.k9.provider.AttachmentProvider.getFile(AttachmentProvider.java:164)

Sounds easy enough to remove the check at AttachmentProvider.java:164

This issue was updated by revision r2356.

Added exception propagation for storage unavaibility Changed some locking logic to operate in a more transactional way (so that it doesn't fail midstream if a concurrent write lock removes the storage)

Update issue 888

I just has a look at the stacktrace from guss77. It does not match the current sourcecode anymore. My guess is that it is already fixed. But I discovered something else:

fiouzy: your r2342 introduced StorageProvider.java... I stored attachments on the SD-card too. You are using public File getAttachmentDirectory(Context context, String id) { return new File(getApplicationDir(context), id + ".db_att"); }

so you are storing attachments on the internal memory (unless app2sd is used). (Unless I'm missing something. Please correct me if I misreat the code.)

While your code is an improvement and very usefull here I think this is design choice is a step backward for the purpose of this ticket. Attachments are often much larger then the email itself and require storage on sd-card even more then the mail-body already does.

Sorry, I did not read enough of the code. Later in that file there was the ExternalStorageProvider that was overriding exactly that line. Sorry.

This issue was updated by revision r2360.

Added localisations for storage-provider names. Added German translations. Added some comments.

Created a new build that includes the great changes made by fiouzy and my localizations. Not signed with the official key, so the market-version of k9 cannot be upgraded using this one. (jessev: could you please? :) )

It looks like issue 1201 already deals with our issue of handling the SD-card not being present?

I've downloaded and installed k9-sdcard3_unsigned.apk (after uninstalling the version from the market place) and when setting up the IMAP connection selected to use the SD card for my message storage, but K9 still seems to be using the internal memory - at least Android | Internal phone storage shows that the amount of free space has decremented 30MB since I installed K9.

I've removed K9 (which gave me back all my space) and reinstalled in case I had accidentally selected Internal memory when I first installed, but this second install is doing exactly the same (and I'm 100% certain I selected SD card).

[Later] I've gone via the settings menu to the accounts settings and it shows internal memory. I've changed it to SD card and it now seems to be using the SD card. So could it be a bug in the initial setup wizard that isn't saving the preferred storage location ?

Looks like it.

When testing the new apk, note that you have to go into account settings again as it will not honor the SD settings of the first versions, that had just a checkbox for the SDcard. I am currently testing it and will see where changes are required to handle removal of the card while running.

PS: Here is the signed version of k9-sdcard3_unsigned.apk
Thanks Jesse :)

http://fsck.com/~jesse/tmp/2010-09-16/1776c301-6573-47a3-8638-01ef28b73204 /K9-release.apk

With App2SD it seems to be no problem to have K9 store mails on SD. (Of cause, since it's silently "uninstalled" and "installed" again when the card comes back as far as the PackageManager and all registred Intents and BroadcastReceivers go.)

With K9 itself being on the phone the first place to add sd-card-removal handling I found is: Account.getLocalStore(Account.java:1141) - suggestion: refuse to give the LocalStore MessagingController.resetVisibleLimits(MessagingController.java:919) - suggestion: handle the case of getting a null K9.onCreate(K9.java:413 - suggestion: handle the case of resetVisibleLimit not doing it's thing

I added LOTS of code to handle LocalStores of Accounts not being there all the time. Basically such accounts they are shown half-transparent in the UI and no operation can be done on them. I also added retry-logic for asyncronous commands.

TODO: * code not tested yet * On the broadcast that signals the sd-card to be about to be removed/re-added we should: ** close the LocalStore's DBs ** have Account.isAvaliable already return false ** get the user back to the account-list to be on the safe side * UI is not refreshed ** this only matters if the user is in the account-list or account-selection

I also added an empty BroadcastReceiver for to be filled.

Having installed the signed version given I cannot see any setting to allow SD storage. Do I need to remove then reinstall rather than update, or am I just missing the option somehow?

Could the flag not just be enabled to allow moving the application to SD card (since I'm running Froyo), does this not fix the problem? Is there a reason this hasn't already been enabled?

Thanks.

See account settings and then incoming server settings. App2sd can not be used by all programs. There are restrictions to it. Out works fine only as long as the card is nearly permanently in the phone. Think e.g. about Widgets using k9. It is enabled in the branch, so you can try it.

This issue was updated by revision r2374.

fixed trivial mistakes from revision r2362

Thanks for working on this branch, really been needing this! I downloaded and compiled your branch, but ran into a Null pointer exception when trying to go to the accounts view. I believe it's due to an incorrect call to set the background color of the accounts that aren't available. The following patch should correct this behavior, but please take a look at it as I haven't done much android development:

A big thank-you to everyone working on this branch. I 'upgraded' to Marcus's signed build (from comment 66) and so far flawless. I was able to switch my accounts to SD and keep my settings so quite painless ...and the joy of not constantly struggling with the 'phone storage full' warnings is incalculable :-)

If I hit any bugs or issues I'll report here.

P.S. The SD storage setting can be hard to find; even with the tips here I foolishly went round in circles a few times on the incoming server settings until I eventually realised I needed to scroll down to see the key SD storage setting!

Issue 2384 has been merged into this issue.

Running the Milestone on Android 2.1 me too have the problem that the k9mail-cache is wasting my telephone-memory rather than the sdcard.

Is there any estimation when the sdcard-patch find it's way into the main branch?

When enough people post that they have tested it and it worked fine for them. It works fine on my phone but 1 person is no acceptable user base to test a patch this deep.

Ok, I'll check the APK provided in comment 66 if I can work with that.

Wow, it worked like charm. Up until now I moved my 5 accounts ( 4x IMAP, 1x POP) to SD-CARD (settings are "hidden" in the inbox-settings of each account) and everything seems to work.

K9 memory usage dropped from ~24MB to ~2MB which gives me a lot air to breathe.

Thank you :-)

I've been running the version posted in comment 61 - k9-sdcard3_unsigned.apk.

Seems to be working well, I've migrated both to/from the SD a few times and it's been solid.

I have had some odd problems where it gets stuck and doesn't download the message content no matter how many times I click 'Check mail' or 'download message text', the messages still have that 'header only' background colour, but I seemed to fix it by migrating back to internal then back to SD again.

I think maybe sometimes my SD gets stressed as I have many apps on Froyo A2SD, so there are lots of encrypted virtual devices mounted which must put a load on the little fella (class 6) when K9 wants to use it with a large mailfile (300+ messages, 5+MB).

If it does it again I'm happy to grab a log from somewhere if that would be useful.

Fiouz mentioned that there are a couple of events we still need to update it to listen for.

Note also that K-9 trunk should be a whole lot better about memory management, even though it sitll keeps things on internal storage.

Well ,an Event handler for sd-removed and sd-added has to be added but all the infrastructure for disabling accounts while the card is gone exists.

I also have a K9 with app2sd running (much simpler). Android just lists the app as not installed as long as the card is not there. db-transactions take care of the rest. Works fine here.

I cannot afford using the current released version of K9 because of limits on internal storage. How will I know when a version who stores messages on the SD card willbe released? Thanks a lot.

I second that. Please release this important feature.

This issue was updated by revision r2565.

Merge mail-on-sd branch from trunk r2564 Commented out accounts background translucency code as it caused NullPointerException on null getBackground()

I thought I already commited a fix for that. I just did not build a new version with it yet.

Is there a possibility someone could build a signed apk with the patch from r2564? That would be great. Thank you.

This issue was updated by revision r2573.

Added infrastructure code to handle storage mount/unmount events Changed from /k9 to /Android/data//files/ directory when storing on SD Card (this is the proper way to benefit the 2.2+ uninstall feature and prevent polluting the SD Card root directory, see http://developer.android.com/guide/topics/data/data-storage.html#filesExternal )

cool, thanks.

I'd like to test sd-card removal some more but don't exactly want to uninstall my constantly used K9 from my phone. (different signing key) Any idea how to test this in an emulator or have both on the same phone? All I can find is that you can't do the sd-removal in am emulator.

@stefanhoth.de: Sorry I can't, only Jesse can do that since he has the release signing key.

@Marcus.Wolschon: You can unmount the SD card in the emulator from the Android settings but I don't know how to simulate seamless SD Card unmounting like HTC Sense ROMs are capable of.

Why should this be blocked on " Issue 2516: Unable to save or open attachments (when SD card unmounted)"?

When the SD-card is unmounted the complete store goes offline and the UI allows no operations on it at all. So no attachments can be opened or saved anyway because no email of that account can be opened (since the email-store is on the card). The account is shown translucent and cannot be selected to be opened.

Comment deleted

Comment deleted

fiouzy: Does your path-change affect current installations of this branch? (don't want testers to loose their mail because it's in a different path now)

• account-setup would not store the storage-setting because no listener was there.

• "refusing to open account that is not avaliable" prevents K9 from starting up if the SD-card is not inserted.

• added log-message on path being mounted/unmounted

• searchLocalMessagesSynchronous was not handling unavaliable accounts yet

• "not opening MessageList of unavaliable account" prevents K9 from being resumed via home-button long-press

• resuming to folder-list now opens account-list if the account is not avaliable

Known issues: * cannot open account from Accounts-list after unmounting and remount SD-card

=> More people need to test this SVN-branch and report logcat stack-tracces, forced closes and errournous behavior before this is in any shape to be included in the trunk. I recomment running this with sd-card removed and removing/reinserting the card while playing around to find bugs.

SVN is "temporarily unavaliable", thus I must attach my changes as a patch. Sorry guys.

Comment deleted

SVN back online, patch applied to our branch.

Marcus:

Old path style DB are indeed ignored and new DB will be created from scratch. Tester willing to keep their DB should manually copy files (from /k9/ to /Android/data/com.fsck.k9/files/) before upgrading.

As a side note, can you prevent from repeatedly adding/removing comments to this issue? I understand you want to keep people informed but that triggers sending of lot of e-mails to subscribed people and some comments don't carry useful payload (I'm not saying not to post comment). Also it seems you're adding TAB as indent characters to the source code and that create inconsistent coding style in the code base. Please don't feel offended by this comment, it's not its purpose.

Regarding testing of features from SVN, and specifically this feature, please note that a lot of users are more then willing to test stuff during development but do not have the build environment needed to build K9. As such providing APK files (even unsigned) for testing is very important wheb you want more testers.

Sorry about that. I guess with the DB also all settings are recreated?

@marcus: Sorry, I haven't checked the sdcard branch in a while. So if I understand you correctly the branch already fixes issue 2516? If you don't mind I'd like to keep the blocker so we remember to also close issue 2516 once this branch is merged into trunk.

@cketti I think it's unrelated as issue 2516 only occurs if mails is stored in internal memory but attachments on SD-card.

Marcus: settings are not cleared/recreated since they are not stored in the account specific DB - that's the same as the "Recreate data (Last Resort!)" feature.

This issue was updated by revision r2576.

Actual implementation of the underlying storage locking: should prevent Android from unmounting while an operation occur is occuring and prevent K-9 from operating on the storage while it's going to be unmounted Removed "synchronized" keyword from the Account migration code (dead locking on migration - should be moved to another class as this class is intended to be a POJO and mixing multipurposed code is confusing)

This issue was updated by revision r2577.

Back to account list when underlying storage not available/unmounting in MessageView / MessageList

This issue was updated by revision r2579.

Added DB close on unmount / DB open on mount

A build of the mail-on-sd branch as of r2582, signed with the release keys:

http://fsck.com/~jesse/tmp/2010-10-28/6605ce6c-3f08-44aa-9402-d683eca0ee63/k9-issue-888-r2582.apk

Thanks for the build. I would have waited until the issue of "unmount SD-card, open K9, be redirected to account-list, remount SD-card, open K9, still cannot enter the account" is resolved.

For anyone suffering from this: turning your device to landscape, so the activity is restarted is a workaround to at least get back into your mail account somehow.

@c107 Thank you very much jessev for the signed update. I installed it and as it was pointed out here, I "lost" my cache files (mail database) due to the new storage location.

In my case it wasn't a big deal since I always work on IMAP-accounts. Nevertheless it might be painful for some POP3-users. So be warned.

Marcus, I'll happily do another build ;)

Fiouzy asked me to do an interim build.

This issue was updated by revision r2603.

Gracefully handle the following situation: 1. SD card is mounted 2. K-9 has account(s) stored on SD card 3. K-9 is running 4. User clicks on "Unmount SD card" in Android settings 5. Android happens to kill K-9 for the following reason: W ActivityManager: Killing processes unmount media at adjustment 2 W ActivityManager: Killing ProcessRecord{44098608 3996:com.fsck.k9/10054} (adj 2): unmount media (I don't know the exact reason behind this, the answer is in Android internal com/android/server/am/ActivityManagerService.java - the point is that it does not always kill K-9) 6. Android broadcasts MEDIA_EJECT (while K-9 isn't running because it was previously killed) 7. Android starts K-9 to handle MEDIA_EJECT using StorageReceiver 8. K-9 starts initializing and attempts to "resetVisibleLimits" for all accounts 9. K-9 attempts to open DB file but can't as Android isn't letting to do so >>> CRASH (obviously because StorageReceiver hasn't been invoked yet at this point which would have prevented account access)

That fix makes 9. handle DB access error (proper exception is thrown) in order to make K-9 not to crash during initialization.

fiouzy: We need to know what view you where in when you left K9.

Another issue: Any search crashes the app. I was unable to get a stacktrace yet.

Full log attached (with r2603 fix), occurs when leaving every activity I tested: Accounts, MessageView, MessageList

This new LockProvider seems to be involved in 2 of the 3 stack-traces. With R2582 I have no problems returning to the app. So it much be due to a later change. Thanks for reporting it!

r2582 has the same problem of being killed by Android and failing at initialization time (there was no verification of the actual filesystem availability before r2603).

What's odd is that Android doesn't seem to kill K-9 when only 1 account is on the SD. With 2 or more accounts on the SD, it kills it (the ActivityManager lines from the log).

OS: OpenDesire 4.0.34 / Android 2.2.1 adb shell getprop | grep ADJ:

Okay, I only have 1 account. That's probably why it die not happen here. Great info.

I think this is a very important feature as with K9 (original) my phone becomes unusable due to low space warning, may even have to un-install k9 to make my phone work... until this "store mail on SDCARD" feature is integrated into main release... how can i clear space on the phone - the "expunge" command doesn't seem to throw-out any of the messages?

Was thinking of trying the patched version, but not sure what limitations are... read that i cant hook up phone to PC, which "mounts" sdcard right?

steve.l.cole:

You can use USB mount with the latest build from Jesse (comment #107), but code is in "beta" state: you may encounter some application crashes (the "Force close" dialog) on mass storage activation. Only the "messages database" is on the SD card: I recommend you using that feature only if you keep a copy of the messages on your server, just in case the DB happens to be corrupted (odds are low, but that feature is hard to bulletproof, moreover since Android is able to kill apps anytime). Settings stay on the phone internal memory and should stay safe.

Dev: We need to remove the MEDIA_EJECT / MEDIA_UNMOUNT filters from the manifest and dynamically register these at initialization time (because it causes K-9 to start with a very bad timing and initialization code isn't safe enough to handle such events).

This issue was updated by revision r2633.

Dynamically register MEDIA_EJECT & MEDIA_UNMOUNT receiver (previous implementation is now splitted into 2 classes) to prevent K-9 from auto-starting at those times if not running (app initialization code isn't safe to run at those times)

I have been using jessev's build for the last week and it works fine. I sometimes get a crash when the phone just starts, but aside from that everything works fine - including attachments. I have two insp accounts configured.

I've just installed this on my Galaxy S and so far it's working fine.

This also seems to noticeable improve performance (see issue 2245: K-9 email slow on Samsung Galaxy S devices), so it would be great if this could make it into mainline.

In combination with reworked/improved preferences handling this could finally make K-9 usable for Galaxy S users who cannot or don't want to root and lagfix their device.

Branch was merged back into trunk as of r2712 and the 3.311 version was built upon it. http://code.google.com/p/k9mail/downloads/list

Please report any problem with using that new feature.

Cool! I'll try the 4h old 3.312 to see if it still crashes instantly on my phone then I try to search. (It logs that it was shut down due to an uncought exception but fails to log the exception+stack trace itself. So it's kind of hard to find out where this is happening and fix it.)

What to expect on the upgrade out of the branch in to 3.312:

• suddenly all my folders except the inbox are gone.

  • folder-list->menu->folders->refresh folders (last menu item) helped and all settings for individual folders are still there.
  • I "just" have to fetch a few gigabytes of mails from these folders again.

• Search now works

  • but no results until I download messages again. Seems it does not employ IMAP-search but only the messages it knows on the phone. (it is set to search "all folders" but clearly not all mails of all folders could ever be on the phone.) Just an observation. Has nothing to do with the sdcard-patches.

• lots of translations are missing. (settings are a crazy mix of German and English)

result: SD-card storage seems to work super-fine now. :) A great thank you to all who tested and especially those who submitted their own patches. The missing translations for many languages for the settings introduced by this branch can probably be handled outside of this ticket. Thank you guys!

I set the ticket to "Fixed". Who and when can set it to "Verified" (or back to "Started" in case of grave shortcommings that do not get handled in their own ticket) in the next days?

Issue 1558 has been merged into this issue.

Hi I use K9-mail on HTC, linking to our mail server (imap) & gmail, I simply use handset as "reader", deleting mails from phone (tho still on servers) Every so often I get phone memory low & K9 is using 40ish Mb phone memory (even with all mails deleted), only solution is to uninstall and reload and then re-create accounts a real bind I read this thread (888), a lot of it going way over my head but I get that I should now be able to store mail to SD (most of my apps are on SD - where possible), but on re-installing K9 I dont see how? (I can set attachments to SD). Is this possible or have I read it wrong? Is there a resolution for the expanding memory usage (even on SD it will eventually get silly) Finally is there any source of "user instructions" for K9

i don't think storing the mails on the sd card will help your memory problem. Try deleting the mails from the trash instead. This helped some users.