
=head1 NAME

Mail::Box::File - handle file-based folders


=head1 INHERITANCE

 Mail::Box::File
   is a Mail::Box
   is a Mail::Reporter

 Mail::Box::File is extended by
   Mail::Box::Dbx
   Mail::Box::Mbox


=head1 SYNOPSIS



=head1 DESCRIPTION

C<Mail::Box::File> is the base-class for all file-based folders: folders
which bundle multiple messages into one single file.  Usually, these
messages are separated by a special line which indicates the start of
the next one.


=head1 OVERLOADED


overload: B<"">

=over 4

See L<Mail::Box/"OVERLOADED">

=back

overload: B<@{}>

=over 4

See L<Mail::Box/"OVERLOADED">

=back

overload: B<cmp>

=over 4

See L<Mail::Box/"OVERLOADED">

=back


=head1 METHODS


=head2 Constructors


Mail::Box::File-E<gt>B<new>(OPTIONS)

=over 4

 Option             Defined in       Default                                                         
 access             L<Mail::Box>     C<'r'>                                                          
 body_delayed_type  L<Mail::Box>     L<Mail::Message::Body::Delayed|Mail::Message::Body::Delayed>    
 body_type                           <see description>                                               
 coerce_options     L<Mail::Box>     C<[]>                                                           
 create             L<Mail::Box>     <false>                                                         
 extract            L<Mail::Box>     C<10240>                                                        
 field_type         L<Mail::Box>     undef                                                           
 fix_headers        L<Mail::Box>     <false>                                                         
 folder             L<Mail::Box>     C<$ENV{MAIL}>                                                   
 folderdir          L<Mail::Box>     C<$ENV{HOME}.'/Mail'>                                           
 head_delayed_type  L<Mail::Box>     L<Mail::Message::Head::Delayed|Mail::Message::Head::Delayed>    
 head_type          L<Mail::Box>     L<Mail::Message::Head::Complete|Mail::Message::Head::Complete>  
 keep_dups          L<Mail::Box>     <false>                                                         
 lock_extension                      C<'.lock'>                                                      
 lock_file          L<Mail::Box>     <foldername>.<lock-extension>                                   
 lock_timeout       L<Mail::Box>     1 hour                                                          
 lock_type          L<Mail::Box>     L<Mail::Box::Locker::DotLock|Mail::Box::Locker::DotLock>        
 lock_wait          L<Mail::Box>     10 seconds                                                      
 locker             L<Mail::Box>     undef                                                           
 log                L<Mail::Reporter>  C<'WARNINGS'>                                                   
 manager            L<Mail::Box>     undef                                                           
 message_type       L<Mail::Box>     L<Mail::Box::File::Message|Mail::Box::File::Message>            
 multipart_type     L<Mail::Box>     L<Mail::Message::Body::Multipart|Mail::Message::Body::Multipart>
 remove_when_empty  L<Mail::Box>     <true>                                                          
 save_on_exit       L<Mail::Box>     <true>                                                          
 trace              L<Mail::Reporter>  C<'WARNINGS'>                                                   
 trusted            L<Mail::Box>     <depends on folder location>                                    
 write_policy                        undef                                                           

. access MODE

. body_delayed_type CLASS

. body_type CLASS|CODE

=over 4

The default C<body_type> option for C<File> folders, which will cause
messages larger than 10kB to be stored in files and smaller files
in memory, is implemented like this:

 sub determine_body_type($$)
 {   my $head = shift;
     my $size = shift || 0;
     'Mail::Message::Body::'
        . ($size > 10000 ? 'File' : 'Lines');
 }

=back

. coerce_options ARRAY

. create BOOLEAN

. extract INTEGER | CODE | METHOD | 'LAZY'|'ALWAYS'

. field_type CLASS

. fix_headers BOOLEAN

. folder FOLDERNAME

. folderdir DIRECTORY

. head_delayed_type CLASS

. head_type CLASS

. keep_dups BOOLEAN

. lock_extension FILENAME|STRING

=over 4

When the dotlock locking mechanism is used, the lock is created with a
hardlink to the folder file.  For C<Mail::Box::File> type of folders, this
file is by default named as the folder-file itself followed by
C<.lock>.  For example: the C<Mail/inbox> folder file will have a hardlink
made as C<Mail/inbox.lock>.

You may specify an absolute filename, a relative (to the folder's
directory) filename, or an extension (preceded by a dot).  So valid
examples are:

 .lock        # appended to the folder's filename
 my_own_lockfile.test   # full filename, same dir
 /etc/passwd            # somewhere else

When the program runs with less priviledges (as normal user), often the
default inbox folder can not be locked with the lockfile name which is
produced by default.

=back

. lock_file FILENAME

. lock_timeout SECONDS

. lock_type CLASS|STRING|ARRAY

. lock_wait SECONDS

. locker OBJECT

. log LEVEL

. manager MANAGER

. message_type CLASS

. multipart_type CLASS

. remove_when_empty BOOLEAN

. save_on_exit BOOLEAN

. trace LEVEL

. trusted BOOLEAN

. write_policy 'REPLACE'|'INPLACE'|undef

=over 4

Sets the default write policy, as default for a later call to
L<write(policy)|Mail::Box::File/"Internals">.  With C<undef>, the best policy is autodetected.

=back

=back

=head2 The folder


$obj-E<gt>B<addMessage>(MESSAGE, OPTIONS)

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<addMessages>(MESSAGE [, MESSAGE, ...])

=over 4

See L<Mail::Box/"The folder">

=back

Mail::Box::File-E<gt>B<appendMessages>(OPTIONS)

=over 4

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.

 Option    Defined in       Default   
 folder    L<Mail::Box>     <required>
 message   L<Mail::Box>     undef     
 messages  L<Mail::Box>     undef     
 share     L<Mail::Box>     <false>   

. folder FOLDERNAME

. message MESSAGE

. messages ARRAY-OF-MESSAGES

. share BOOLEAN

=back

$obj-E<gt>B<close>(OPTIONS)

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<copyTo>(FOLDER, OPTIONS)

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<delete>(OPTIONS)

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<filename>

=over 4

Returns the filename for this folder, which may be an absolute or relative
path to the file.

I<Example:> 

 print $folder->filename;

=back

$obj-E<gt>B<folderdir>([DIRECTORY])

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<name>

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<organization>

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<size>

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<type>

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<update>(OPTIONS)

=over 4

See L<Mail::Box/"The folder">

=back

$obj-E<gt>B<url>

=over 4

See L<Mail::Box/"The folder">

=back

=head2 Folder flags


$obj-E<gt>B<access>

=over 4

See L<Mail::Box/"Folder flags">

=back

$obj-E<gt>B<isModified>

=over 4

See L<Mail::Box/"Folder flags">

=back

$obj-E<gt>B<modified>([BOOLEAN])

=over 4

See L<Mail::Box/"Folder flags">

=back

$obj-E<gt>B<writable>

=over 4

See L<Mail::Box/"Folder flags">

=back

=head2 The messages


$obj-E<gt>B<current>([NUMBER|MESSAGE|MESSAGE-ID])

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<find>(MESSAGE-ID)

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<findFirstLabeled>(LABEL, [BOOLEAN, [ARRAY-OF-MSGS]])

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<message>(INDEX [,MESSAGE])

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<messageId>(MESSAGE-ID [,MESSAGE])

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<messageIds>

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<messages>(['ALL',RANGE,'ACTIVE','DELETED',LABEL,!LABEL,FILTER])

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<nrMessages>(OPTIONS)

=over 4

See L<Mail::Box/"The messages">

=back

$obj-E<gt>B<scanForMessages>(MESSAGE, MESSAGE-IDS, TIMESPAN, WINDOW)

=over 4

See L<Mail::Box/"The messages">

=back

=head2 Sub-folders


$obj-E<gt>B<listSubFolders>(OPTIONS)

Mail::Box::File-E<gt>B<listSubFolders>(OPTIONS)

=over 4

See L<Mail::Box/"Sub-folders">

=back

$obj-E<gt>B<nameOfSubFolder>(SUBNAME, [PARENTNAME])

Mail::Box::File-E<gt>B<nameOfSubFolder>(SUBNAME, [PARENTNAME])

=over 4

See L<Mail::Box/"Sub-folders">

=back

$obj-E<gt>B<openRelatedFolder>(OPTIONS)

=over 4

See L<Mail::Box/"Sub-folders">

=back

$obj-E<gt>B<openSubFolder>(SUBNAME, OPTIONS)

=over 4

See L<Mail::Box/"Sub-folders">

=back

$obj-E<gt>B<topFolderWithMessages>

Mail::Box::File-E<gt>B<topFolderWithMessages>

=over 4

See L<Mail::Box/"Sub-folders">

=back

=head2 Internals


$obj-E<gt>B<coerce>(MESSAGE, OPTIONS)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<create>(FOLDERNAME, OPTIONS)

Mail::Box::File-E<gt>B<create>(FOLDERNAME, OPTIONS)

=over 4

 Option     Defined in    Default
 folderdir  L<Mail::Box>  undef  

. folderdir DIRECTORY

=back

$obj-E<gt>B<determineBodyType>(MESSAGE, HEAD)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<folderToFilename>(FOLDERNAME, FOLDERDIR, [SUBEXT])

Mail::Box::File-E<gt>B<folderToFilename>(FOLDERNAME, FOLDERDIR, [SUBEXT])

=over 4

Translate a folder name into a filename, using the
FOLDERDIR value to replace a leading C<=>.  SUBEXT is only used for MBOX
folders.

=back

Mail::Box::File-E<gt>B<foundIn>([FOLDERNAME], OPTIONS)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<lineSeparator>([STRING|'CR'|'LF'|'CRLF'])

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<locker>

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<messageCreateOptions>([TYPE, CONFIG])

=over 4

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 L<readMessages()|Mail::Box/"Internals"> and L<updateMessages()|Mail::Box::File/"Internals">.  With
TYPE and CONFIG, a new configuration is set.

=back

$obj-E<gt>B<moveAwaySubFolder>(DIRECTORY, EXTENSION)

=over 4

The DIRECTORY is renamed by appending the EXTENSION, which defaults to C<".d">,
to make place for a folder file on that specific location.  C<false> is
returned if this failed.

=back

$obj-E<gt>B<parser>

=over 4

Create a parser for this mailbox.  The parser stays alive as long as
the folder is open.

=back

$obj-E<gt>B<read>(OPTIONS)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<readMessages>(OPTIONS)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<storeMessage>(MESSAGE)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<toBeThreaded>(MESSAGES)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<toBeUnthreaded>(MESSAGES)

=over 4

See L<Mail::Box/"Internals">

=back

$obj-E<gt>B<updateMessages>(OPTIONS)

=over 4

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...

=back

$obj-E<gt>B<write>(OPTIONS)

=over 4

 Option        Defined in       Default
 force         L<Mail::Box>     <false>
 policy                         undef  
 save_deleted  L<Mail::Box>     <false>

. force BOOLEAN

. policy 'REPLACE'|'INPLACE'|undef

=over 4

In what way will the mail folder be updated.  If not specified during the
write, the value of the L<new(write_policy)|Mail::Box::File/"METHODS"> at folder creation is taken.

Valid values:

=over 4

=item * C<REPLACE>

First a new folder is written in the same directory as the folder which has
to be updated, and then a call to move will throw away the old immediately
replacing it by the new.

Writing in C<REPLACE> module is slightly optimized: messages which are not 
modified are copied from file to file, byte by byte.  This is much
faster than printing the data which is will be done for modified messages.

=item * C<INPLACE>

The original folder file will be opened read/write.  All message which where
not changed will be left untouched, until the first deleted or modified
message is detected.  All further messages are printed again.

=item * C<undef>

As default, or when C<undef> is explicitly specified, first C<REPLACE> mode
is tried.  Only when that fails, an C<INPLACE> update is performed.

=back

C<INPLACE> will be much faster than C<REPLACE> when applied on large
folders, however requires the C<truncate> function to be implemented on
your operating system (at least available for recent versions of Linux,
Solaris, Tru64, HPUX).  It is also dangerous: when the program is interrupted
during the update process, the folder is corrupted.  Data may be lost.

However, in some cases it is not possible to write the folder with
C<REPLACE>.  For instance, the usual incoming mail folder on UNIX is
stored in a directory where a user can not write.  Of course, the
C<root> and C<mail> users can, but if you want to use this Perl module
with permission of a normal user, you can only get it to work in C<INPLACE>
mode.  Be warned that in this case folder locking via a lockfile is not
possible as well.

=back

. save_deleted BOOLEAN

=back

$obj-E<gt>B<writeMessages>(OPTIONS)

=over 4

See L<Mail::Box/"Internals">

=back

=head3 File based folders

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 L<Mail::Box::Dir|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.

=head3 File based folders

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 L<Mail::Box::Dir|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.

=head2 Other methods


$obj-E<gt>B<timespan2seconds>(TIME)

Mail::Box::File-E<gt>B<timespan2seconds>(TIME)

=over 4

See L<Mail::Box/"Other methods">

=back

=head2 Error handling


$obj-E<gt>B<AUTOLOAD>

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<addReport>(OBJECT)

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<defaultTrace>([LEVEL]|[LOGLEVEL, TRACELEVEL]|[LEVEL, CALLBACK])

Mail::Box::File-E<gt>B<defaultTrace>([LEVEL]|[LOGLEVEL, TRACELEVEL]|[LEVEL, CALLBACK])

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<errors>

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<log>([LEVEL [,STRINGS]])

Mail::Box::File-E<gt>B<log>([LEVEL [,STRINGS]])

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<logPriority>(LEVEL)

Mail::Box::File-E<gt>B<logPriority>(LEVEL)

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<logSettings>

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<notImplemented>

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<report>([LEVEL])

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<reportAll>([LEVEL])

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<trace>([LEVEL])

=over 4

See L<Mail::Reporter/"Error handling">

=back

$obj-E<gt>B<warnings>

=over 4

See L<Mail::Reporter/"Error handling">

=back

=head2 Cleanup


$obj-E<gt>B<DESTROY>

=over 4

See L<Mail::Box/"Cleanup">

=back

$obj-E<gt>B<inGlobalDestruction>

=over 4

See L<Mail::Reporter/"Cleanup">

=back



=head1 DIAGNOSTICS

I<Error:> Cannot append messages to folder file $filename: $!

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.

I<Error:> Cannot create directory $dir for folder $name.

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.

I<Error:> Cannot create folder file $name: $!

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.

I<Error:> Cannot get a lock on $type folder $self.

A lock is required to get access to the folder.  If no locking is needed,
specify the NONE lock type.

I<Error:> Cannot move away sub-folder $dir


I<Warning:> Cannot remove folder $name file $filename: $!

Writing an empty folder will usually cause that folder to be removed,
which fails for the indicated reason.  L<new(remove_when_empty)|Mail::Box/"Constructors">

I<Warning:> Cannot remove folder $name file $filename: $!

Writing an empty folder will usually cause that folder to be removed,
which fails for the indicated reason.  L<new(remove_when_empty)|Mail::Box/"Constructors">
controls whether the empty folder will removed; setting it to false
(C<0>) may be needed to avoid this message.

I<Error:> Cannot replace $filename by $tempname, to update folder $name: $!

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.

I<Warning:> Changes not written to read-only folder $self.

You have opened the folder read-only --which is the default set
by L<new(access)|Mail::Box/"Constructors">--, made modifications, and now want to close it.
Set L<close(force)|Mail::Box/"The folder"> if you want to overrule the access mode, or close
the folder with L<close(write)|Mail::Box/"The folder"> set to C<NEVER>.

I<Error:> Copying failed for one message.

For some reason, for instance disc full, removed by external process, or
read-protection, it is impossible to copy one of the messages.  Copying will
proceed for the other messages.

I<Error:> Destination folder $name is not writable.

The folder where the messages are copied to is not opened with write
access (see L<new(access)|Mail::Box/"Constructors">).  This has no relation with write permission
to the folder which is controled by your operating system.

I<Warning:> Different messages with id $msgid.

The message id is discovered more than once within the same folder, but the
content of the message seems to be different.  This should not be possible:
each message must be unique.

I<Error:> File too short to get write message $nr ($size, $need)

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.

I<Warning:> Folder $name file $filename is write-protected.

The folder is opened writable or for appending via L<new(access)|Mail::Box/"Constructors">,
but the operating system does not permit writing to the file.  The folder
will be opened read-only.

I<Error:> Folder $name not deleted: not writable.

The folder must be opened with write access via L<new(access)|Mail::Box/"Constructors">, otherwise
removing it will be refused.  So, you may have write-access according to
the operating system, but that will not automatically mean that this
C<delete> method permits you to.  The reverse remark is valid as well.

I<Error:> Invalid timespan '$timespan' specified.

The string does not follow the strict rules of the time span syntax which
is permitted as parameter.

I<Warning:> Message-id '$msgid' does not contain a domain.

According to the RFCs, message-ids need to contain a unique random part,
then an C<@>, and then a domain name.  This is made to avoid the creation
of two messages with the same id.  The warning emerges when the C<@> is
missing from the string.

I<Error:> Package $package does not implement $method.

Fatal error: the specific package (or one of its superclasses) does not
implement this method where it should. This message means that some other
related classes do implement this method however the class at hand does
not.  Probably you should investigate this and probably inform the author
of the package.

I<Error:> Unable to create subfolder $name of $folder.

The copy includes the subfolders, but for some reason it was not possible
to copy one of these.  Copying will proceed for all other sub-folders.

I<Error:> Unable to update folder $self.

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.


=head1 DETAILS






=head1 REFERENCES

See the MailBox website at L<http://perl.overmeer.net/mailbox/> for more details.

=head1 COPYRIGHTS

Distribution version 2.058.
Written by Mark Overmeer (mark@overmeer.net).  See the ChangeLog for
other contributors.

Copyright (c) 2001-2003 by the author(s). All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.


