See METHODS in Mail::Reporter
Option | Defined in | Default |
---|---|---|
access | Mail::Box |
|
body_delayed_type | Mail::Box | |
body_type | <see description> | |
coerce_options | Mail::Box |
|
create | Mail::Box | <false> |
extract | Mail::Box |
|
field_type | Mail::Box | undef |
fix_headers | Mail::Box | <false> |
folder | Mail::Box |
|
folderdir | Mail::Box |
|
head_delayed_type | Mail::Box | |
head_type | Mail::Box | |
keep_dups | Mail::Box | <false> |
lock_extension |
| |
lock_file | Mail::Box | <foldername><lock-extension> |
lock_timeout | Mail::Box | 1 hour |
lock_type | Mail::Box | |
lock_wait | Mail::Box | 10 seconds |
locker | Mail::Box | undef |
log | Mail::Reporter |
|
manager | Mail::Box | undef |
message_type | Mail::Box | |
multipart_type | Mail::Box | |
remove_when_empty | Mail::Box | <true> |
save_on_exit | Mail::Box | <true> |
trace | Mail::Reporter |
|
trusted | Mail::Box | <depends on folder location> |
write_policy | undef |
A lock is required to get access to the folder. If no locking is needed, specify the NONE lock type.
The folder is opened writable or for appending via new(access), but the operating system does not permit writing to the file. The folder will be opened read-only.
Appending messages to a file based folder which is not opened is a little risky. In practice, this is often done without locking the folder. So, an other application may write to the folder at the same time... :( Hopefully, all goes fast enough that the chance on collition is small.
All OPTIONS of Mail::Box::Mbox::new() can be supplied.
Option | Defined in | Default |
---|---|---|
folder | Mail::Box | <required> |
lock_type |
| |
message | Mail::Box | undef |
messages | Mail::Box | undef |
share | Mail::Box | <false> |
Appending messages to a not-opened file-organized folder may fail when the operating system does not allow write access to the file at hand.
Option | Defined in | Default |
---|---|---|
folderdir | Mail::Box | undef |
While creating a file-organized folder, at most one level of directories is created above it. Apparently, more levels of directories are needed, or the operating system does not allow you to create the directory.
The file-organized folder file cannot be created for the indicated reason. In common cases, the operating system does not grant you write access to the directory where the folder file should be stored.
Translate a folder name into a filename, using the
FOLDERDIR value to replace a leading =
. SUBEXT is only used for MBOX
folders.
Returns a key-value list of options to be used each time a new message is read from a file. The list is preceeded by the TYPE of message which has to be created.
This data is used by readMessages() and updateMessages(). With TYPE and CONFIG, a new configuration is set.
The DIRECTORY is renamed by appending the EXTENSION, which defaults to ".d"
,
to make place for a folder file on that specific location. false
is
returned if this failed.
Create a parser for this mailbox. The parser stays alive as long as the folder is open.
For file based folders, the file handle stays open until the folder is closed. Update is therefore rather simple: move to the end of the last known message, and continue reading...
Option | Defined in | Default |
---|---|---|
force | Mail::Box | <false> |
policy | undef | |
save_deleted | Mail::Box | <false> |
Writing an empty folder will usually cause that folder to be removed, which fails for the indicated reason. new(remove_when_empty)
Writing an empty folder will usually cause that folder to be removed,
which fails for the indicated reason. new(remove_when_empty)
controls whether the empty folder will removed; setting it to false
(0
) may be needed to avoid this message.
The replace policy wrote a new folder file to update the existing, but was unable to give the final touch: replacing the old version of the folder file for the indicated reason.
Mail::Box is lazy: it tries to leave messages in the folders until they are used, which saves time and memory usage. When this message appears, something is terribly wrong: some lazy message are needed for updating the folder, but they cannot be retreived from the original file anymore. In this case, messages can be lost.
This message does appear regularly on Windows systems when using the 'replace' write policy. Please help to find the cause, probably something to do with Windows incorrectly handling multiple filehandles open in the same file.
When a folder is to be written, both replace and inplace write policies are tried, If both fail, the whole update fails. You may see other, related, error messages to indicate the real problem.
File based folders maintain a folder (a set of messages) in one single file. The advantage is that your folder has only one single name, which speeds-up access to all messages at once.
The disadvantage over directory based folder (see Mail::Box::Dir) is that you have to construct some means to keep all message apart, for instance by adding a message separator, and this will cause problems. Where access to all messages at once is faster in file based folders, access to a single message is (much) slower, because the whole folder must be read.
File based folders maintain a folder (a set of messages) in one single file. The advantage is that your folder has only one single name, which speeds-up access to all messages at once.
The disadvantage over directory based folder (see Mail::Box::Dir) is that you have to construct some means to keep all message apart, for instance by adding a message separator, and this will cause problems. Where access to all messages at once is faster in file based folders, access to a single message is (much) slower, because the whole folder must be read.