From 7255122bc9520b571a4ced4532c3a5a03705692e Mon Sep 17 00:00:00 2001 From: yamaoka Date: Mon, 10 Mar 2003 00:11:01 +0000 Subject: [PATCH] Synch to Oort Gnus 200303100008 (The "Maildir" section in gnus-ja.texi has not been translated yet). --- lisp/ChangeLog | 5 ++ lisp/gnus-agent.el | 3 +- texi/ChangeLog | 4 + texi/gnus-ja.texi | 242 +++++++++++++++++++++++++++++++++++++++++++++++++++- texi/gnus.texi | 242 +++++++++++++++++++++++++++++++++++++++++++++++++++- 5 files changed, 486 insertions(+), 10 deletions(-) diff --git a/lisp/ChangeLog b/lisp/ChangeLog index dcab063..531473c 100644 --- a/lisp/ChangeLog +++ b/lisp/ChangeLog @@ -1,3 +1,8 @@ +2003-03-10 Jesper Harder + + * gnus-agent.el (gnus-agent-synchronize-flags-server): Don't use + kill-line. + 2003-03-09 Jesper Harder * gnus-msg.el (gnus-inews-insert-archive-gcc): Don't use diff --git a/lisp/gnus-agent.el b/lisp/gnus-agent.el index c192405..a897188 100644 --- a/lisp/gnus-agent.el +++ b/lisp/gnus-agent.el @@ -763,8 +763,7 @@ be a select method." (gnus-message 1 "Couldn't open server %s" (nth 1 gnus-command-method)) (while (not (eobp)) (if (null (eval (read (current-buffer)))) - (progn (forward-line) - (kill-line -1)) + (gnus-delete-line) (write-file (gnus-agent-lib-file "flags")) (error "Couldn't set flags from file %s" (gnus-agent-lib-file "flags")))) diff --git a/texi/ChangeLog b/texi/ChangeLog index 4b6cb75..971ea00 100644 --- a/texi/ChangeLog +++ b/texi/ChangeLog @@ -1,3 +1,7 @@ +2003-03-09 Paul Jarc + + * gnus.texi (Maildir): New node. + 2003-03-08 Jesper Harder * gnusref.tex: Update. diff --git a/texi/gnus-ja.texi b/texi/gnus-ja.texi index 0093c57..16f1603 100644 --- a/texi/gnus-ja.texi +++ b/texi/gnus-ja.texi @@ -13624,10 +13624,7 @@ Gnus はメールグループを動作するようにするとメールスプールを読み込みます。 標準の gnus では六つの違ったメールバックエンドがあり、個別にさらなるバッ クエンドを使用可能です。ほとんどの人が使うメールバックエンドは (それがた -ぶん最速だから) @code{nnml} です (@pxref{Mail Spool})。あなたは以下に五 -つのバックエンドしかないことに気が付くでしょう; @code{nnmaildir} の文献 -はまだこのマニュアルに完全に編入されていないのです。それまで -は @uref{http://multivac.cwru.edu./nnmaildir/} で見つけることができます。 +ぶん最速だから) @code{nnml} です (@pxref{Mail Spool})。 @menu * Unix Mail Box:: (とても) 標準的な Un*x mbox を使う @@ -13635,6 +13632,7 @@ Gnus はメールグループを動作するようにするとメールスプールを読み込みます。 マットを使う * Mail Spool:: あなたのメールを私的なスプールに溜める? * MH Spool:: mhspool のようなバックエンド +* Maildir:: もう一つの１ファイル/１メッセージ形式 * Mail Folders:: それぞれのグループに対して一つのファイル を持つ * Comparing Mail Back Ends:: 得失の深い洞察 @@ -13839,6 +13837,242 @@ rmail box のためのアクティブファイルの名前。既定値 る必要はありません。既定値は @code{nil} です。 @end table +@c TRANSLATEME! +@node Maildir +@subsubsection Maildir +@cindex nnmaildir +@cindex maildir + +@code{nnmaildir} stores mail in the maildir format, with each maildir +corresponding to a group in Gnus. This format is documented here: +@uref{http://cr.yp.to/proto/maildir.html} and here: +@uref{http://www.qmail.org/man/man5/maildir.html}. nnmaildir also +stores extra information in the @file{.nnmaildir/} directory within a +maildir. + +Maildir format was designed to allow concurrent deliveries and +reading, without needing locks. With other backends, you would have +your mail delivered to a spool of some kind, and then you would +configure Gnus to split mail from that spool into your groups. You +can still do that with nnmaildir, but the more common configuration is +to have your mail delivered directly to the maildirs that appear as +group in Gnus. + +nnmaildir is designed to be perfectly reliable: @kbd{C-g} will never +corrupt its data in memory, and @code{SIGKILL} will never corrupt its +data in the filesystem. + +nnmaildir stores article marks and NOV data in each maildir. So you +can copy a whole maildir from one Gnus setup to another, and you will +keep your marks. + +Virtual server settings: + +@table @code +@item directory +For each of your nnmaildir servers (it's very unlikely that you'd need +more than one), you need to create a directory and populate it with +symlinks to maildirs (and nothing else; do not choose a directory +already used for other purposes). You could also put maildirs +themselves (instead of symlinks to them) directly in the server +directory, but that would break @code{nnmaildir-request-delete-group}, +so you wouldn't be able to delete those groups from within Gnus. (You +could still delete them from your shell with @code{rm -r foo}.) Each +maildir will be represented in Gnus as a newsgroup on that server; the +filename of the symlink will be the name of the group. Any filenames +in the directory starting with `.' are ignored. The directory is +scanned when you first start Gnus, and each time you type @kbd{g} in +the group buffer; if any maildirs have been removed or added, +nnmaildir notices at these times. + +The value of the @code{directory} parameter should be a Lisp form +which is processed by @code{eval} and @code{expand-file-name} to get +the path of the directory for this server. The form is @code{eval}ed +only when the server is opened; the resulting string is used until the +server is closed. (If you don't know about forms and @code{eval}, +don't worry - a simple string will work.) This parameter is not +optional; you must specify it. I don't recommend using @file{~/Mail} +or a subdirectory of it; several other parts of Gnus use that +directory by default for various things, and may get confused if +nnmaildir uses it too. @file{~/.nnmaildir} is a typical value. + +@item create-directory +This should be a Lisp form which is processed by @code{eval} and +@code{expand-file-name} to get the name of the directory where new +maildirs are created. The form is @code{eval}ed only when the server +is opened; the resulting string is used until the server is closed. +This parameter is optional, but if you do not supply it, you cannot +create new groups from within Gnus. (You could still create them from +your shell with @code{mkdir -m 0700 foo foo/tmp foo/new foo/cur}.) A +relative path is interpreted as relative to the @code{directory} path. +@code{create-directory} and @code{directory} must be different; +otherwise, group creation and deletion will break. (If you don't need +those features, you can omit @code{create-directory} entirely.) + +@item directory-files +This should be a function with the same interface as +@code{directory-files} (such as @code{directory-files} itself). It is +used to scan the server's @code{directory} for maildirs. This +parameter is optional; the default is +@code{nnheader-directory-files-safe} if +@code{nnheader-directory-files-is-safe} is @code{nil}, and +@code{directory-files} otherwise. +(@code{nnheader-directory-files-is-safe} is checked only once when the +server is opened; if you want to check it each time the directory is +scanned, you'll have to provide your own function that does that.) + +@item get-new-mail +If non-@code{nil}, then after scanning for new mail in the group +maildirs themselves as usual, this server will also incorporate mail +the conventional Gnus way, from @code{mail-sources} according to +@code{nnmail-split-methods} or @code{nnmail-split-fancy}. The default +value is @code{nil}. + +Do @emph{not} use the same maildir both in @code{mail-sources} and as +an nnmaildir group. The results might happen to be useful, but that +would be by chance, not by design, and the results might be different +in the future. If your split rules create new groups, remember to +supply a @code{create-directory} server parameter. +@end table + +@subsubsection Group parameters + +nnmaildir uses several group parameters. It's safe to ignore all +this; the default behavior for nnmaildir is the same as the default +behavior for other mail backends: articles are deleted after one week, +etc. Except for the expiry parameters, all this functionality is +unique to nnmaildir, so you can ignore it if you're just trying to +duplicate the behavior you already have with another backend. + +If the value of any of these parameters is a vector, the first element +is evaluated as a Lisp form and the result is used, rather than the +original value. If the value is not a vector, the value itself is +evaluated as a Lisp form. (This is why these parameters use names +different from those of other, similar parameters supported by other +backends: they have different, though similar, meanings.) (For +numbers, strings, @code{nil}, and @code{t}, you can ignore the +@code{eval} business again; for other values, remember to use an extra +quote and wrap the value in a vector when appropriate.) + +@table @code +@item expire-age +An integer specifying the minimum age, in seconds, of an article before +it will be expired, or the symbol @code{never} to specify that +articles should never be expired. If this parameter is not set, +nnmaildir falls back to the usual +@code{nnmail-expiry-wait}(@code{-function}) variables (overridable by +the @code{expiry-wait}(@code{-function}) group parameters. If you +wanted a value of 3 days, you could use something like @code{[(* 3 24 +60 60)]}; nnmaildir will evaluate the form and use the result. An +article's age is measured starting from the article file's +modification time. Normally, this is the same as the article's +delivery time, but editing an article makes it younger. Moving an +article (other than via expiry) may also make an article younger. + +@item expire-group +If this is set to a string (a full Gnus group name, like +@code{"backend+server.address.string:group.name"}), and if it is not +the name of the same group that the parameter belongs to, then +articles will be moved to the specified group during expiry before +being deleted. @emph{If this is set to an nnmaildir group, the +article will be just as old in the destination group as it was in the +source group.} So be careful with @code{expire-age} in the destination +group. + +@item read-only +If this is set to @code{t}, nnmaildir will treat the articles in this +maildir as read-only. This means: articles are not renamed from +@file{new/} into @file{cur/}; articles are only found in @file{new/}, +not @file{cur/}; articles are never deleted; articles cannot be +edited. @file{new/} is expected to be a symlink to the @file{new/} +directory of another maildir - e.g., a system-wide mailbox containing +a mailing list of common interest. Everything in the maildir outside +@file{new/} is @emph{not} treated as read-only, so for a shared +mailbox, you do still need to set up your own maildir (or have write +permission to the shared mailbox); your maildir just won't contain +extra copies of the articles. + +@item directory-files +A function with the same interface as @code{directory-files}. It is +used to scan the directories in the maildir corresponding to this +group to find articles. The default is the function specified by the +server's @code{directory-files} parameter. + +@item always-marks +A list of mark symbols, such as +@code{['(read expire)]}. Whenever Gnus asks nnmaildir for +article marks, nnmaildir will say that all articles have these +marks, regardless of whether the marks stored in the filesystem +say so. This is a proof-of-concept feature that will probably be +removed eventually; it ought to be done in Gnus proper, or +abandoned if it's not worthwhile. + +@item never-marks +A list of mark symbols, such as @code{['(tick expire)]}. Whenever +Gnus asks nnmaildir for article marks, nnmaildir will say that no +articles have these marks, regardless of whether the marks stored in +the filesystem say so. @code{never-marks} overrides +@code{always-marks}. This is a proof-of-concept feature that will +probably be removed eventually; it ought to be done in Gnus proper, or +abandoned if it's not worthwhile. + +@item nov-cache-size +An integer specifying the size of the NOV memory cache. To speed +things up, nnmaildir keeps NOV data in memory for a limited number of +articles in each group. (This is probably not worthwhile, and will +probably be removed in the future.) This parameter's value is noticed +only the first time a group is seen after the server is opened - i.e., +when you first start Gnus, typically. The NOV cache is never resized +until the server is closed and reopened. The default is an estimate +of the number of articles that would be displayed in the summary +buffer: a count of articles that are either marked with @code{tick} or +not marked with @code{read}, plus a little extra. +@end table + +@subsubsection Article identification +Articles are stored in the @file{cur/} subdirectory of each maildir. +Each article file is named like @code{uniq:info}, where @code{uniq} +contains no colons. nnmaildir ignores, but preserves, the +@code{:info} part. (Other maildir readers typically use this part of +the filename to store marks.) The @code{uniq} part uniquely +identifies the article, and is used in various places in the +@file{.nnmaildir/} subdirectory of the maildir to store information +about the corresponding article. The full pathname of an article is +available in the variable @code{nnmaildir-article-file-name} after you +request the article in the summary buffer. + +@subsubsection NOV data +An article identified by @code{uniq} has its NOV data (used to +generate lines in the summary buffer) stored in +@code{.nnmaildir/nov/uniq}. There is no +@code{nnmaildir-generate-nov-databases} function. (There isn't much +need for it - an article's NOV data is updated automatically when the +article or @code{nnmail-extra-headers} has changed.) You can force +nnmaildir to regenerate the NOV data for a single article simply by +deleting the corresponding NOV file, but @emph{beware}: this will also +cause nnmaildir to assign a new article number for this article, which +may cause trouble with @code{seen} marks, the Agent, and the cache. + +@subsubsection Article marks +An article identified by @code{uniq} is considered to have the mark +@code{flag} when the file @file{.nnmaildir/marks/flag/uniq} exists. +When Gnus asks nnmaildir for a group's marks, nnmaildir looks for such +files and reports the set of marks it finds. When Gnus asks nnmaildir +to store a new set of marks, nnmaildir creates and deletes the +corresponding files as needed. (Actually, rather than create a new +file for each mark, it just creates hard links to +@file{.nnmaildir/markfile}, to save inodes.) + +You can invent new marks by creating a new directory in +@file{.nnmaildir/marks/}. You can tar up a maildir and remove it from +your server, untar it later, and keep your marks. You can add and +remove marks yourself by creating and deleting mark files. If you do +this while Gnus is running and your nnmaildir server is open, it's +best to exit all summary buffers for nnmaildir groups and type @kbd{s} +in the group buffer first, and to type @kbd{g} or @kbd{M-g} in the +group buffer afterwards. Otherwise, Gnus might not pick up the +changes, and might undo them. + @node Mail Folders @subsubsection メールフォルダー @cindex nnfolder diff --git a/texi/gnus.texi b/texi/gnus.texi index 97358b7..b430429 100644 --- a/texi/gnus.texi +++ b/texi/gnus.texi @@ -14276,16 +14276,14 @@ depends on what format you want to store your mail in. There are six different mail back ends in the standard Gnus, and more back ends are available separately. The mail back end most people use (because it is possibly the fastest) is @code{nnml} (@pxref{Mail -Spool}). You might notice that only five back ends are listed below; -@code{nnmaildir}'s documentation has not yet been completely -incorporated into this manual. Until it is, you can find it at -@uref{http://multivac.cwru.edu./nnmaildir/}. +Spool}). @menu * Unix Mail Box:: Using the (quite) standard Un*x mbox. * Rmail Babyl:: Emacs programs use the rmail babyl format. * Mail Spool:: Store your mail in a private spool? * MH Spool:: An mhspool-like back end. +* Maildir:: Another one-file-per-message format. * Mail Folders:: Having one file for each group. * Comparing Mail Back Ends:: An in-depth looks at pros and cons. @end menu @@ -14497,6 +14495,242 @@ to set this variable to @code{t}. The default is @code{nil}. @end table +@node Maildir +@subsubsection Maildir +@cindex nnmaildir +@cindex maildir + +@code{nnmaildir} stores mail in the maildir format, with each maildir +corresponding to a group in Gnus. This format is documented here: +@uref{http://cr.yp.to/proto/maildir.html} and here: +@uref{http://www.qmail.org/man/man5/maildir.html}. nnmaildir also +stores extra information in the @file{.nnmaildir/} directory within a +maildir. + +Maildir format was designed to allow concurrent deliveries and +reading, without needing locks. With other backends, you would have +your mail delivered to a spool of some kind, and then you would +configure Gnus to split mail from that spool into your groups. You +can still do that with nnmaildir, but the more common configuration is +to have your mail delivered directly to the maildirs that appear as +group in Gnus. + +nnmaildir is designed to be perfectly reliable: @kbd{C-g} will never +corrupt its data in memory, and @code{SIGKILL} will never corrupt its +data in the filesystem. + +nnmaildir stores article marks and NOV data in each maildir. So you +can copy a whole maildir from one Gnus setup to another, and you will +keep your marks. + +Virtual server settings: + +@table @code +@item directory +For each of your nnmaildir servers (it's very unlikely that you'd need +more than one), you need to create a directory and populate it with +symlinks to maildirs (and nothing else; do not choose a directory +already used for other purposes). You could also put maildirs +themselves (instead of symlinks to them) directly in the server +directory, but that would break @code{nnmaildir-request-delete-group}, +so you wouldn't be able to delete those groups from within Gnus. (You +could still delete them from your shell with @code{rm -r foo}.) Each +maildir will be represented in Gnus as a newsgroup on that server; the +filename of the symlink will be the name of the group. Any filenames +in the directory starting with `.' are ignored. The directory is +scanned when you first start Gnus, and each time you type @kbd{g} in +the group buffer; if any maildirs have been removed or added, +nnmaildir notices at these times. + +The value of the @code{directory} parameter should be a Lisp form +which is processed by @code{eval} and @code{expand-file-name} to get +the path of the directory for this server. The form is @code{eval}ed +only when the server is opened; the resulting string is used until the +server is closed. (If you don't know about forms and @code{eval}, +don't worry - a simple string will work.) This parameter is not +optional; you must specify it. I don't recommend using @file{~/Mail} +or a subdirectory of it; several other parts of Gnus use that +directory by default for various things, and may get confused if +nnmaildir uses it too. @file{~/.nnmaildir} is a typical value. + +@item create-directory +This should be a Lisp form which is processed by @code{eval} and +@code{expand-file-name} to get the name of the directory where new +maildirs are created. The form is @code{eval}ed only when the server +is opened; the resulting string is used until the server is closed. +This parameter is optional, but if you do not supply it, you cannot +create new groups from within Gnus. (You could still create them from +your shell with @code{mkdir -m 0700 foo foo/tmp foo/new foo/cur}.) A +relative path is interpreted as relative to the @code{directory} path. +@code{create-directory} and @code{directory} must be different; +otherwise, group creation and deletion will break. (If you don't need +those features, you can omit @code{create-directory} entirely.) + +@item directory-files +This should be a function with the same interface as +@code{directory-files} (such as @code{directory-files} itself). It is +used to scan the server's @code{directory} for maildirs. This +parameter is optional; the default is +@code{nnheader-directory-files-safe} if +@code{nnheader-directory-files-is-safe} is @code{nil}, and +@code{directory-files} otherwise. +(@code{nnheader-directory-files-is-safe} is checked only once when the +server is opened; if you want to check it each time the directory is +scanned, you'll have to provide your own function that does that.) + +@item get-new-mail +If non-@code{nil}, then after scanning for new mail in the group +maildirs themselves as usual, this server will also incorporate mail +the conventional Gnus way, from @code{mail-sources} according to +@code{nnmail-split-methods} or @code{nnmail-split-fancy}. The default +value is @code{nil}. + +Do @emph{not} use the same maildir both in @code{mail-sources} and as +an nnmaildir group. The results might happen to be useful, but that +would be by chance, not by design, and the results might be different +in the future. If your split rules create new groups, remember to +supply a @code{create-directory} server parameter. +@end table + +@subsubsection Group parameters + +nnmaildir uses several group parameters. It's safe to ignore all +this; the default behavior for nnmaildir is the same as the default +behavior for other mail backends: articles are deleted after one week, +etc. Except for the expiry parameters, all this functionality is +unique to nnmaildir, so you can ignore it if you're just trying to +duplicate the behavior you already have with another backend. + +If the value of any of these parameters is a vector, the first element +is evaluated as a Lisp form and the result is used, rather than the +original value. If the value is not a vector, the value itself is +evaluated as a Lisp form. (This is why these parameters use names +different from those of other, similar parameters supported by other +backends: they have different, though similar, meanings.) (For +numbers, strings, @code{nil}, and @code{t}, you can ignore the +@code{eval} business again; for other values, remember to use an extra +quote and wrap the value in a vector when appropriate.) + +@table @code +@item expire-age +An integer specifying the minimum age, in seconds, of an article before +it will be expired, or the symbol @code{never} to specify that +articles should never be expired. If this parameter is not set, +nnmaildir falls back to the usual +@code{nnmail-expiry-wait}(@code{-function}) variables (overridable by +the @code{expiry-wait}(@code{-function}) group parameters. If you +wanted a value of 3 days, you could use something like @code{[(* 3 24 +60 60)]}; nnmaildir will evaluate the form and use the result. An +article's age is measured starting from the article file's +modification time. Normally, this is the same as the article's +delivery time, but editing an article makes it younger. Moving an +article (other than via expiry) may also make an article younger. + +@item expire-group +If this is set to a string (a full Gnus group name, like +@code{"backend+server.address.string:group.name"}), and if it is not +the name of the same group that the parameter belongs to, then +articles will be moved to the specified group during expiry before +being deleted. @emph{If this is set to an nnmaildir group, the +article will be just as old in the destination group as it was in the +source group.} So be careful with @code{expire-age} in the destination +group. + +@item read-only +If this is set to @code{t}, nnmaildir will treat the articles in this +maildir as read-only. This means: articles are not renamed from +@file{new/} into @file{cur/}; articles are only found in @file{new/}, +not @file{cur/}; articles are never deleted; articles cannot be +edited. @file{new/} is expected to be a symlink to the @file{new/} +directory of another maildir - e.g., a system-wide mailbox containing +a mailing list of common interest. Everything in the maildir outside +@file{new/} is @emph{not} treated as read-only, so for a shared +mailbox, you do still need to set up your own maildir (or have write +permission to the shared mailbox); your maildir just won't contain +extra copies of the articles. + +@item directory-files +A function with the same interface as @code{directory-files}. It is +used to scan the directories in the maildir corresponding to this +group to find articles. The default is the function specified by the +server's @code{directory-files} parameter. + +@item always-marks +A list of mark symbols, such as +@code{['(read expire)]}. Whenever Gnus asks nnmaildir for +article marks, nnmaildir will say that all articles have these +marks, regardless of whether the marks stored in the filesystem +say so. This is a proof-of-concept feature that will probably be +removed eventually; it ought to be done in Gnus proper, or +abandoned if it's not worthwhile. + +@item never-marks +A list of mark symbols, such as @code{['(tick expire)]}. Whenever +Gnus asks nnmaildir for article marks, nnmaildir will say that no +articles have these marks, regardless of whether the marks stored in +the filesystem say so. @code{never-marks} overrides +@code{always-marks}. This is a proof-of-concept feature that will +probably be removed eventually; it ought to be done in Gnus proper, or +abandoned if it's not worthwhile. + +@item nov-cache-size +An integer specifying the size of the NOV memory cache. To speed +things up, nnmaildir keeps NOV data in memory for a limited number of +articles in each group. (This is probably not worthwhile, and will +probably be removed in the future.) This parameter's value is noticed +only the first time a group is seen after the server is opened - i.e., +when you first start Gnus, typically. The NOV cache is never resized +until the server is closed and reopened. The default is an estimate +of the number of articles that would be displayed in the summary +buffer: a count of articles that are either marked with @code{tick} or +not marked with @code{read}, plus a little extra. +@end table + +@subsubsection Article identification +Articles are stored in the @file{cur/} subdirectory of each maildir. +Each article file is named like @code{uniq:info}, where @code{uniq} +contains no colons. nnmaildir ignores, but preserves, the +@code{:info} part. (Other maildir readers typically use this part of +the filename to store marks.) The @code{uniq} part uniquely +identifies the article, and is used in various places in the +@file{.nnmaildir/} subdirectory of the maildir to store information +about the corresponding article. The full pathname of an article is +available in the variable @code{nnmaildir-article-file-name} after you +request the article in the summary buffer. + +@subsubsection NOV data +An article identified by @code{uniq} has its NOV data (used to +generate lines in the summary buffer) stored in +@code{.nnmaildir/nov/uniq}. There is no +@code{nnmaildir-generate-nov-databases} function. (There isn't much +need for it - an article's NOV data is updated automatically when the +article or @code{nnmail-extra-headers} has changed.) You can force +nnmaildir to regenerate the NOV data for a single article simply by +deleting the corresponding NOV file, but @emph{beware}: this will also +cause nnmaildir to assign a new article number for this article, which +may cause trouble with @code{seen} marks, the Agent, and the cache. + +@subsubsection Article marks +An article identified by @code{uniq} is considered to have the mark +@code{flag} when the file @file{.nnmaildir/marks/flag/uniq} exists. +When Gnus asks nnmaildir for a group's marks, nnmaildir looks for such +files and reports the set of marks it finds. When Gnus asks nnmaildir +to store a new set of marks, nnmaildir creates and deletes the +corresponding files as needed. (Actually, rather than create a new +file for each mark, it just creates hard links to +@file{.nnmaildir/markfile}, to save inodes.) + +You can invent new marks by creating a new directory in +@file{.nnmaildir/marks/}. You can tar up a maildir and remove it from +your server, untar it later, and keep your marks. You can add and +remove marks yourself by creating and deleting mark files. If you do +this while Gnus is running and your nnmaildir server is open, it's +best to exit all summary buffers for nnmaildir groups and type @kbd{s} +in the group buffer first, and to type @kbd{g} or @kbd{M-g} in the +group buffer afterwards. Otherwise, Gnus might not pick up the +changes, and might undo them. + + @node Mail Folders @subsubsection Mail Folders @cindex nnfolder -- 1.7.10.4