search for: is_readonly

...d on object _creation_ (or load time) and not only when validation happens. So the approach used in "attr_readonly" doesn''t work since it''s a class method. I could of course, do something like ReadonlyAttributes = [:firstname, :lastname, :gender_id, :birthdate] def is_readonly?(attr) true if ReadonlyAttributes.include?(attr) and self.passport_verified? end def validate ReadonlyAttributes.each do |attr| errors.add(attr, "You cannot change #{attr}!") if attr.changed? end end only that "changed?" in this context would probably...

> > Can you do > > p *box $1 = {name = 0x5555557e1f18 "Junk", vname = 0x5555557e1f10 "Junk", storage = 0x5555557e1860, list = 0x5555557e1050, v = { is_readonly = 0x7ffff76e5a50 <fail_mailbox_is_readonly>, enable = 0x7ffff76e5a60 <fail_mailbox_enable>, exists = 0x7ffff76e5a70 <fail_mailbox_exists>, open = 0x7ffff76e5e60 <fail_mailbox_open>, close = 0x7ffff69cf800 <quota_mailbox_close>, free = 0x7ffff69d0370...

On 30.08.2017 12:55, Stef?n Tam?s wrote: >> Can you do >> >> p *box > $1 = {name = 0x5555557e1f18 "Junk", vname = 0x5555557e1f10 "Junk", > storage = 0x5555557e1860, list = 0x5555557e1050, v = { > is_readonly = 0x7ffff76e5a50 <fail_mailbox_is_readonly>, > Something goes wrong when opening "Junk" mailbox. Are you sure it exists? Can you doveadm with doveadm -Dv search -u email at example.com mailbox Junk savedbefore 30d Aki

Hi, We have a Ubuntu 14.04 server with dovecot 2.2.9 If I try to run /usr/bin/doveadm search -u email at exmaple.com mailbox Junk savedbefore 30d It will dump a core file. We have a similar config on an other server and there is no problem there. Any ideas how to prevent the core dump? root at triws2:~# gdb --args doveadm search -u email at example.com mailbox Junk savedbefore 30d Reading

...ain.c:229 (gdb) up 4 #4 0x000355e0 in mbox_lock (mbox=0xaedc8, lock_type=2, lock_id_r=0xffbff5ec) at mbox-lock.c:521 521 i_assert(mbox->ibox.index->lock_type != F_WRLCK); (gdb) print *mbox $1 = {ibox = {box = {name = 0xaef10 "INBOX", storage = 0xa3200, v = { is_readonly = 0x4456c <index_storage_is_readonly>, allow_new_keywords = 0x44578 <index_storage_allow_new_keywords>, close = 0x335a8 <mbox_storage_close>, get_status = 0x43b94 <index_storage_get_status>, sync_init = 0x3b228 <mbox_storage_sync_init>,...

To some users happens this assertion failure while deleting a message. dovecot: Mar 10 08:40:44 Panic: IMAP(user): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists (&ibox->recent_flags, uid)) dovecot: Mar 10 08:40:44 Error: IMAP(user): Raw backtrace: [see bleow] dovecot: Mar 10 08:40:44 Error: child 17683 (imap) killed with signal 6 And the

Hi list, Recently I was debugging L2 guest slow booting issue in nested virtualization environment (both L0 and L1 hypervisors are all Xen). To boot a L2 Linux guest (RHEL6u2), it will need to wait more than 3 minutes after grub loaded, I did some profile, and see guest is doing disk operations by int13 BIOS procedure. Even not consider the nested case, I saw there is a bug reporting normal VM

...AILBOX_SYNC_FLAG_FULL_READ (gdb) up #8 0x00028370 in imap_sync_nonselected (box=0xbb3d0, flags=MAILBOX_SYNC_FLAG_FULL_READ) at imap-sync.c:195 195 ctx = mailbox_sync_init(box, flags); (gdb) print *box $7 = {name = 0xbb528 "sent-mail-apr-2004", storage = 0xb1978, v = { is_readonly = 0x4d498 <index_storage_is_readonly>, allow_new_keywords = 0x4d4a4 <index_storage_allow_new_keywords>, close = 0x33258 <mbox_storage_close>, get_status = 0x4d46c <index_storage_get_status>, sync_init = 0x3c6ac <mbox_storage_sync_init>, sync_next =...

On Fri, Jul 31, 2015 at 6:18 PM, Reid Kleckner <rnk at google.com> wrote: > Consider this pseudo-IR and some possible transforms that I would expect to > be semantics preserving: > > void f(i32* readonly %a, i32* %b) { > llvm.assume(%a == %b) > store i32 42, i32* %b > } > ... > %p = alloca i32 > store i32 13, i32* %p > call f(i32* readonly %p,

As promised, here it is finally. v1.0 is getting nearer and I want people to start looking at Dovecot's sources. Getting some more help with development would be nice, but I'd also like to hear if there are any hidden bugs in the code. So, one week from now I'll start offering 1000 EUR for the first person to point out a remotely exploitable security hole in Dovecot. See

----- Forwarded message ----- Date: Sat, 18 Feb 2017 22:21:19 -0500 Subject: nbdkit async Hello, Hope this is the right person to contact regarding nbdkit design. I have a high latency massively parallel device that I am currently implementing as an nbdkit plugin in c++ and have run into some design limitations due to the synchronous callback interface nbdkit requires. Nbdkit is currently

...// do error stuff; } else if (op->cmd == NBD_CMD_READ) send_reply(op, op->buf, op->count, 0); else send_reply(op, NULL, 0, 0); } int my_plugin_pwrite_lowlevel (void *op, void *handle, void *buf, uint32_t count, uint64_t offset) { if (is_readonly(handle)) { nbdkit_reply_error (op, EROFS); return 0; } if (some critically bad issue) return -1; // this returns right away before write has completed and when it // does complete calls the handler lambda my_storage.async_write(buf, count, offset, [op, count](cons...