search for: write_fds

Dear Tinc-devs, trying to compile Tinc 1.1 pre 15 on my Gentoo system, I get the following error: ----------------------------------------- uml_device.c: In function ‘read_packet’: uml_device.c:231:25: error: incompatible type for argument 2 of ‘connect’ if(connect(write_fd, (const struct sockkadr *)&request.sock, sizeof request.sock) < 0) { ^ In file included

...nd has data to read + * - write_fd is nonnegative and can be written to + * - something terrible happened to either + * - the timeout (in milliseconds) has elapsed + * Return value is zero iff the timeout occured. + */ +char await_fds(int read_fd, int write_fd, int timeout_ms) +{ + fd_set read_fds, write_fds, except_fds; + struct timeval tv; + int res; + + tv.tv_sec = timeout_ms/1000; + tv.tv_usec = (timeout_ms%1000)*1000; + + while (1) { + FD_ZERO(&read_fds); + FD_ZERO(&write_fds); + FD_ZERO(&except_fds); + if (write_fd>=0) { + FD_SET(write_fd, &write_fds); + FD_SET(...

Here is another crash we've been seeing recently in rc15 on Solaris 10. (gdb) bt full #0 0xff1c12a4 in ?? () No symbol table info available. #1 0xff140040 in ?? () No symbol table info available. #2 0x000786a8 in t_buffer_alloc (size=688976) at data-stack.c:346 __PRETTY_FUNCTION__ = "file %s: line %" #3 0x00078190 in t_pop () at data-stack.c:149 frame_block = (struct

...small typo in src/lib/ioloop-select.c: --- dovecot-1.0.alpha4/src/lib/ioloop-select.c.orig 2005-11-06 22:06:53.000000000 -0800 +++ dovecot-1.0.alpha4/src/lib/ioloop-select.c 2005-11-06 22:07:13.000000000 -0 800 @@ -113,7 +113,7 @@ sizeof(fd_set)); memcpy(&tmp_write_fds, &ioloop->handler_context->write_fds, sizeof(fd_set)); - memcpy(&tmp_except_fds, &ioloop->handler_data->except_fds, + memcpy(&tmp_except_fds, &ioloop->handler_context->except_fds, sizeof(fd_set)); ret = selec...

Hi, on a clustered Dovecot server installation that was recently moved from a shared GPFS filesystem to GFS2, occasional corruptions in the users' INBOXes started appearing, where a new incoming message would be appended directly after a block of NUL bytes, and be scanned by dovecot as being glued to the preceding message. I traced this to the file extension operation performed in

https://bugzilla.mindrot.org/show_bug.cgi?id=2948 Bug ID: 2948 Summary: implement "copy-data" sftp extension Product: Portable OpenSSH Version: -current Hardware: All URL: https://tools.ietf.org/html/draft-ietf-secsh-filexfer- extensions-00#section-7 OS: All Status: NEW

Hi All, Here's an rsync patch which adds an --offline flag, letting you transfer changed blocks via removable media, while still comparing checksums via the net. I expect this could be very popular for the growing number of people who want to do disk-based offsite backups, which is what I needed it for. It took me longer than I hoped, but still only several hours to work this out -- it

...dovecot-1.0-test35/src/lib/ioloop-select.c --- dovecot-1.0-test35.vanilla/src/lib/ioloop-select.c 2004-08-23 17:46:41.000000000 +0400 +++ dovecot-1.0-test35/src/lib/ioloop-select.c 2004-08-25 10:55:25.000000000 +0400 @@ -17,8 +17,27 @@ struct ioloop_handler_data { static fd_set tmp_read_fds, tmp_write_fds; +static void update_highest_fd(struct ioloop *ioloop) +{ + struct io *io; + int max_highest_fd; + + max_highest_fd = ioloop->highest_fd-1; + ioloop->highest_fd = -1; + + for (io = ioloop->ios; io != NULL; io = io->next) { + if (!io->destroyed && io->fd &g...

Most fixes are trivial. The one from Alex is fixing a real bug that several users have reported. Alex sent the patch half a year ago and it was not yet integrated. The patch "Use /proc/mounts instead of /etc/mtab" is a repost. The patch "btrfs-receive optionally honors the end-cmd" is a preparation step to allow backup tools to multiplex a single communication stream (e.g. a

When I submitted the qcow2 patch for blktap, suggestions came up that the qemu block drivers should be used also for blktap to eliminate the current code duplication in ioemu and blktap. The attached patch adds support for a tap:ioemu pseudo driver. Devices using this driver won''t use tapdisk (containing the code duplication) any more, but will connect to the qemu-dm of the domain. In

Timo, My first assert in beta2. Syslog said: Jan 24 09:57:16 emerald dovecot: [ID 107833 mail.error] imap(user): Cached message offset 94625 is invalid for mbox file /var/mail/m/user Jan 24 09:57:16 emerald dovecot: [ID 107833 mail.error] imap(user): file mbox-sync.c: line 1471 (mbox_sync_do): assertion failed: (!sync_ctx->mbox->mbox_sync_dirty || (flags & MBOX_SYNC_UNDIRTY) == 0) Gdb

Hi Benjamin: I think that the following link will give you an idea for what you need to know: http://www.cisco.com/warp/customer/620/roadmap_b.shtml This is for the naming: http://www.cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080101cda.shtml In this case 11.1CC goes to 12.0T and 12.0T migrate to 12.1 mainline. Do not you worry you will not loose anything with the new

Dovecot 1.1.7 is running so smoothly that I gave up checking its log files daily. :) I've just had a look, and among the usual "IMAP(username): FETCH for mailbox Sent UID xx got too little data: xx vs xx" messages (that means that unfortunately sometimes some messages are still written truncated) I saw this assertion failure: file mbox-sync.c: line 1305

...+void io_loop_handle_add(struct ioloop *ioloop, struct io *io) { + enum io_condition condition = io->condition; + int fd = io->fd; + i_assert(fd >= 0); if (fd >= FD_SETSIZE) @@ -44,9 +46,11 @@ void io_loop_handle_add(struct ioloop *i FD_SET(fd, &ioloop->handler_data->write_fds); } -void io_loop_handle_remove(struct ioloop *ioloop, int fd, - enum io_condition condition) +void io_loop_handle_remove(struct ioloop *ioloop, struct io *io) { + enum io_condition condition = io->condition; + int fd = io->fd; + i_assert(fd >= 0 && fd < FD_SETSIZE);...

Timo, Attached is gdb information from core dumps related to the following assert in test-80: IMAP(username): file mbox-sync-update.c: line 442 (mbox_sync_update_header_from): assertion failed: (ctx->mail.uid == 0 || ctx->mail.uid_broken || ctx->mail.uid == mail->uid) My setup: Solaris 9, mbox format. test-80 compiled with gcc 4.0.1 using the following configure options: CC=gcc

Hi, When the Dovecot 1.0.rc19 IMAP server encounters X-UID headers with gaps in them, it hangs indefinitely. I've attached a sample mailbox (in mbox format) which repeatably exhibits this behavior. The mbox contains only three messages with the following X-UIDs in order: 774, 785, 787. If I remove the X-UID headers from each message, Dovecot handles the mailbox without any problems. UW-IMAP

It might not be a fault in dovecot, as the user is accessing the folder locally with alpine while also running imap-sessions. However it would have been nice with a more graceful action than panic? The panic is preceeded by Error: Next message unexpectedly corrupted in mbox file PATH Panic: file mbox-sync.c: line 152 (mbox_sync_read_next_mail): assertion failed:

This patch series copies the core of the tapdisk process from blktap2, with updates coming from blktap2.5. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

This patch series introduces the shared ring used by the front-end to pass request descriptors to tapdisk, as well as responses from tapdisk to the front-end. Requests from this ring end up in tapdisk''s standard request queue. When the tapback daemon detects that the front-end tries to connect to the back-end, it spawns a tapdisk and tells it to connect to the shared ring. The shared