Displaying 3 results from an estimated 3 matches for "mtime_r".
Did you mean:
ctime_r
2008 Dec 09
1
Possible bug in Maildir++ quota?
While researching a possible bug in our custom-made Maildir++ expiration
script, I found the following in src/plugins/quota/quota-maildir.c.
| static const char *
| maildir_list_next(struct maildir_list_context *ctx, time_t *mtime_r)
| {
| [...]
| *mtime_r = st.st_size;
| return str_c(ctx->path);
| }
As far as I unterstand, this seems incorrect, because the value in mtime_r
is used, for example, in maildirs_check_have_changed to check whether any
maildirs or folders have changed.
If this isn't a bug, pleas...
2009 Feb 04
1
location of temporary files in deliver
deliver has the following:
-- -- --
/* After buffer grows larger than this, create a temporary file to /tmp
where to read the mail. */
#define MAIL_MAX_MEMORY_BUFFER (1024*128)
...
static struct istream *create_raw_stream(int fd, time_t *mtime_r)
...
input = i_stream_create_seekable(input_list, MAIL_MAX_MEMORY_BUFFER,
"/tmp/dovecot.deliver.");
-- -- --
On most of my systems, /tmp is relatively small (a few hundred MB, and sometimes
on ramdisk), and I like to use /var/tmp for lar...
2013 Jun 05
2
dovecot and time
I found something interesting via strace. lda is writing a timestamp
with utime before doign the fsync, but I'm really not a C guy, so I
have no idea why that's going on via procmail and not via commandline.
I assume it's related to the choice of pread64 vs read.
when called from commandline (working):
read(0, "July 14-20, 2013\n10 courses. Bon"..., 4096) = 4096