Recover 9GB of e-mail from /cur
I use my iPhone to read mail from my primary Cpanel mail account, but do not have it set to delete mails.
On an increasingly infrequent basis, I have also checked e-mail with Eudora on my laptop which becomes my permanent archive of received e-mails. Unfortunately I guess I have let it go too long as I now have 9GB of e-mail in the /cur folder of my cPanel account and am now unable to retrieve it on my PC.
9GB is beyond the limits that Squirrelmail and any other tool I've attempted are able to handle. Even trying to do a listing (ls) of the /cur directory never finishes. Trying to do a gzip gives me "argument list too long". I cannot get POP3 logins to work for that account anymore.
So what can I do to recover this 9GB of e-mail?
-
Hello :) Mail in the "cur" directory indicates it's already been delivered to the inbox. You are welcome to move this mail out of the way if necessary. It's located at: /home/$username/mail/$domain.com/$email-account/cur
Thank you.0 -
Thank you for your response, but I've afraid you've missed the point of my request. :( 0 -
[quote="feldon27, post: 1537501">Thank you for your response, but you've rather missed the point of my request.
Unfortunately, if your email clients are not able to handle the number of emails in the Inbox, it's likely a good idea to move the emails out of the way temporarily and review/delete the emails you no longer require. You can do this by manually moving certain email files out of the way (e.g. files with file names ending with 1) until it's down enough to load in your email client. Thank you.0 -
Ok, let's try this again. I have 9GB of e-mails in /cur. I want to download those e-mails to an e-mail client. Obviously /cur was never intended for this purpose. To resolve the issue, do I rename /new to something else and then rename /cur to /new and try checking e-mail again? Is that really all it takes, or is there some value or flag set somewhere that I need to change or run a script to get it to rescan my inbox? Also, due to the size of /cur, I am unable to do anything with it as it sits. I'm guessing it's up in the tens of thousands of filenames in a single directory which is, of course, a big no-no on Linux. Trying to navigate to /cur with FileZilla hangs until it times out. Running a du -h /cur spins indefinitely. Squirrelmail fails after several minutes. Basically anything I try to access this mail hangs or fails. Due to the size, I'm sure a gzip all would fail with a "too many parameters" as well. I can try your suggestion of a mv *1 to another folder and see if that makes it small enough to do anything, but I don't have a lot of hope. And just to repeat: I do NOT want to delete the 9GB of e-mail. I want to access it somehow. 0 -
You are welcome to move the mail files to the "new" directory to ensure it's detected as new email by your email client. Note that mail likely already exists in the "new" directory for this email account, so you may want to check that new email first before renaming the existing "cur" directory to "new" or moving mail files out of it. One thing to consider is to use POP3 in your email client instead of IMAP if you want to ensure the mail is not stored on the server after you download it. Thank you. 0 -
I can't use mv or any other standard function due to "argument list too long" so I am inside /cur and am trying this: find . -iname "*1.*" -exec mv {} ../new \; I guess we'll see what happens. UPDATE: It seems to be working as I am now downloading 30,000 e-mails. Now for *2.*, *3.*, etc. 0 -
You could try using xargs in a command like the one in this example: [url=http://stackoverflow.com/questions/11289551/argument-list-too-long-error-for-rm-cp-mv-commands]linux - Argument list too long error for rm, cp, mv commands - Stack Overflow Note that you would replace "rm" with a "mv" command in the example. Thank you. 0
Please sign in to leave a comment.
Comments
7 comments