I'm on AIX reading the local mail file, which is held in /var/spool/mail/myuserid
I can read mail OK and the permission bits on THAT mail file show that I am the owner and I can read-write the file.
However, when I set the delete flag on a msg and call folder.close(true) it fails because either MSTOR or javamail are trying to create a temporary mail file /var/spool/mail/myuserid.tmp !! Obviously I cant create other files in this system directory...
So, how can I solve this? Is there a setting to turn the TMP file creation off? Or redirect it to a different directory?
Thanks!
CJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting problem. I didn't consider not being able to write to the directory. Anyway, I've just made a change to create the temp file in the system temp directory, which I think all users should be able to write to.
Now I've been doing some pretty major refactoring of the mstor architecture lately, so I'm not entirely confident that everything from CVS works as well as the current release (0.9.10), although the unit tests do all pass which is a good sign. So anyway, if you would like to try this change you can get the latest snapshot build from here:
Thanks for your response. I tried your SNAPSHOT, but it got the same error. I then tried to update the SNAPSHOT source but couldnt get it to compile - it doesnt have the ANT build setup and has a lot of changes as you said.
I found your code change in MboxFile.java and applied it to the 0.9.10 release. There were 3 total changes required to make it work :
In purge() :
// Create the new file in the temp directory which is always read/write
File newFile = new File(System.getProperty("java.io.tmpdir"),
file.getName() + TEMP_FILE_EXTENSION);
// Create the temp file in the temp directory which is always read/write
File tempFile = new File(System.getProperty("java.io.tmpdir"),
file.getName() + "." + System.currentTimeMillis());
And in renameTo() :
// Try to delete the source file, but if it doesnt work, oh well
try { source.delete(); }
catch( Exception e ) {}
success = true;
So now it is working, although I dislike having my own 'special' copy of the code.
Just out of curiosity, where do most people use MSTOR that this permission bit problem hasn't occurred before? Do other AIX or UNIX systems allow users to create files in the /var/spool/mail directory?
CJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok I've added the additional change to create the new file in the temp directory, however I'm not sure this is going to work properly.. If the original mail file is renamed (to the temp file), is the new file able to be renamed to the original mail file (i.e. are permissions on the original filename retained after it is renamed?). Anyway I guess it just requires some testing..
Also I don't believe "source.delete()" will throw any exception in renameTo(), so I've left out this part for now. Let me know if you think otherwise.
As for why this issue hasn't come up sooner, from what I can tell I think it is more common to use mstor to read Thunderbird mailboxes than UNIX mail files, and I think Thunderbird stores mail in the home directory right? Also Windows users won't have a problem due to the simplistic file permissions and everyone running as Administrator anyway. ;)
regards,
ben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code I pasted here does work for me, it is now part of my project. :) Since the 'renameTo' is really a copy and delete, yes - the permissions on the file are maintained. The file is opened for writing, not appending, so the contents are completely overwritten.
And "source.delete()" DID throw an exception for the original file in the /var/spool/mail directory, so the "catch" was required.
Ah... I get that. Yes, I'd much rather be reading TB mail files... Unix/AIX is SUCH a pain in the ass when it comes to permission bits. And it never makes sense with directory vs file permissions. Why can I delete every byte within a file, but not the file itself??
Anyway, the updates I made were required for it to work, but I'm sure you'll want to test them yourself.
Thanks for your help...
CJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm on AIX reading the local mail file, which is held in /var/spool/mail/myuserid
I can read mail OK and the permission bits on THAT mail file show that I am the owner and I can read-write the file.
However, when I set the delete flag on a msg and call folder.close(true) it fails because either MSTOR or javamail are trying to create a temporary mail file /var/spool/mail/myuserid.tmp !! Obviously I cant create other files in this system directory...
So, how can I solve this? Is there a setting to turn the TMP file creation off? Or redirect it to a different directory?
Thanks!
CJ
Hi CJ,
Interesting problem. I didn't consider not being able to write to the directory. Anyway, I've just made a change to create the temp file in the system temp directory, which I think all users should be able to write to.
Now I've been doing some pretty major refactoring of the mstor architecture lately, so I'm not entirely confident that everything from CVS works as well as the current release (0.9.10), although the unit tests do all pass which is a good sign. So anyway, if you would like to try this change you can get the latest snapshot build from here:
http://m2.modularity.net.au/snapshots/net/fortuna/mstor/0.9.11-SNAPSHOT/
If you have any problems with this build that you would like me to look into then let me know.
regards,
ben
Hi Ben,
Thanks for your response. I tried your SNAPSHOT, but it got the same error. I then tried to update the SNAPSHOT source but couldnt get it to compile - it doesnt have the ANT build setup and has a lot of changes as you said.
I found your code change in MboxFile.java and applied it to the 0.9.10 release. There were 3 total changes required to make it work :
In purge() :
// Create the new file in the temp directory which is always read/write
File newFile = new File(System.getProperty("java.io.tmpdir"),
file.getName() + TEMP_FILE_EXTENSION);
// Create the temp file in the temp directory which is always read/write
File tempFile = new File(System.getProperty("java.io.tmpdir"),
file.getName() + "." + System.currentTimeMillis());
And in renameTo() :
// Try to delete the source file, but if it doesnt work, oh well
try { source.delete(); }
catch( Exception e ) {}
success = true;
So now it is working, although I dislike having my own 'special' copy of the code.
Just out of curiosity, where do most people use MSTOR that this permission bit problem hasn't occurred before? Do other AIX or UNIX systems allow users to create files in the /var/spool/mail directory?
CJ
Hi CJ,
Ok I've added the additional change to create the new file in the temp directory, however I'm not sure this is going to work properly.. If the original mail file is renamed (to the temp file), is the new file able to be renamed to the original mail file (i.e. are permissions on the original filename retained after it is renamed?). Anyway I guess it just requires some testing..
Also I don't believe "source.delete()" will throw any exception in renameTo(), so I've left out this part for now. Let me know if you think otherwise.
As for why this issue hasn't come up sooner, from what I can tell I think it is more common to use mstor to read Thunderbird mailboxes than UNIX mail files, and I think Thunderbird stores mail in the home directory right? Also Windows users won't have a problem due to the simplistic file permissions and everyone running as Administrator anyway. ;)
regards,
ben
Hi Ben,
The code I pasted here does work for me, it is now part of my project. :) Since the 'renameTo' is really a copy and delete, yes - the permissions on the file are maintained. The file is opened for writing, not appending, so the contents are completely overwritten.
And "source.delete()" DID throw an exception for the original file in the /var/spool/mail directory, so the "catch" was required.
Ah... I get that. Yes, I'd much rather be reading TB mail files... Unix/AIX is SUCH a pain in the ass when it comes to permission bits. And it never makes sense with directory vs file permissions. Why can I delete every byte within a file, but not the file itself??
Anyway, the updates I made were required for it to work, but I'm sure you'll want to test them yourself.
Thanks for your help...
CJ