It's what I'd expect. In fact, it's what UFS does. Renaming a file
doesn't change it's inode.
That's not true for the Solaris 9 implementation of UFS:
Sorry, I meant UFS on NetBSD. I didn't know Solaris would behave
differently.
Bill Cole wrote:
At 12:27 PM +0100 2/14/08, Edgar Fuß wrote:
Am 13.02.2008 um 14:56 schrieb Bill Cole:
Not on all filesystems. Note what HFS+ (MacOS) does:
~ $ ls -lc foo
-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foodir/foo
-rwxr-xr-x
Bill Cole wrote:
At 11:53 PM +0100 2/13/08, mouss imposed structure on a stream of
electrons, yielding:
Bill Cole wrote:
[...]
Not on all filesystems. Note what HFS+ (MacOS) does:
~ $ ls -lc foo
-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foo
On Thursday, February 14 at 09:50 AM, quoth Bill Cole:
I'm curious: do you have examples of mail software that doesn't use
the timestamp? (I could see some run-once script not doing it, but
I'd be surprised if widely-used software didn't.)
The procmailrc man page says that MSGPREFIX defaults t
On Thu, 2008-02-14 at 00:25 -0500, Benjamin R. Haskell wrote:
> And, as Charles pointed out, in Dovecot 1.1 there's a plugin to do this.
> Does the expunge plugin work without the user logging in, though?
Yes. That's exactly what it does. It keeps user/mailbox <-> oldest_msg
mapping in a Berkele
At 11:53 PM +0100 2/13/08, mouss imposed structure on a stream of
electrons, yielding:
Bill Cole wrote:
[...]
Not on all filesystems. Note what HFS+ (MacOS) does:
~ $ ls -lc foo
-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foodir/foo
-rwxr-xr-x
At 12:27 PM +0100 2/14/08, Edgar Fuß wrote:
>Am 13.02.2008 um 14:56 schrieb Bill Cole:
>
>>Not on all filesystems. Note what HFS+ (MacOS) does:
>>
>>~ $ ls -lc foo
>>-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo
>>~ $ mkdir foodir
>>~ $ mv foo foodir
>>~ $ ls -lc foodir/foo
>>-rwxr-xr-x 1 wkc wk
At 12:25 AM -0500 2/14/08, Benjamin R. Haskell imposed structure on
a stream of electrons, yielding:
On Wed, 13 Feb 2008, Bill Cole wrote:
[...]
Maildir DOES NOT require a timestamp in the filename, it's just common.
DJB's Maildir spec isn't RFC-esque (so it's not a MUST, in that
sense).
Am 13.02.2008 um 14:56 schrieb Bill Cole:
Not on all filesystems. Note what HFS+ (MacOS) does:
~ $ ls -lc foo
-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foodir/foo
-rwxr-xr-x 1 wkc wkc 332 Jan 29 03:32 foodir/foo
~ $ date
Wed Feb 13 08:39:24
On 2/14/2008, Benjamin R. Haskell ([EMAIL PROTECTED]) wrote:
And, as Charles pointed out, in Dovecot 1.1 there's a plugin to do
this. Does the expunge plugin
Actually, its the 'Expire' plugin... ;)
work without the user logging in, though? (not that that's an
enormous problem -- more curiosit
On Wed, 13 Feb 2008, Bill Cole wrote:
At 12:21 AM -0500 2/13/08, Benjamin R. Haskell imposed structure on a stream
of electrons, yielding:
On Wed, 13 Feb 2008, Rody wrote:
Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
Yes, but you may also care that ctime is reset when a client has
At 3:24 PM +0100 2/13/08, Andrea Perotti wrote:
Bill Cole ha scritto:
(one can argue that HFS+ is Bad and Wrong in many ways, but it is
in widespread use...)
Widespread? On servers?
I suppose that's a matter of definition, but Apple was one of the top
10 server hardware vendors in the last
On Wed, 13 Feb 2008, mouss wrote:
Bill Cole wrote:
At 12:21 AM -0500 2/13/08, Benjamin R. Haskell imposed structure on a
stream of electrons, yielding:
[...] Under most *nix filesystems, ctime is the last time the inode
underlying the file/dir was changed ('c' for "changed", not "created"
Bill Cole wrote:
At 12:21 AM -0500 2/13/08, Benjamin R. Haskell imposed structure on a stream
of electrons, yielding:
On Wed, 13 Feb 2008, Rody wrote:
Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
Yes, but you may also care that ctime is reset when a client has
Doveco
At 7:55 AM +0200 2/13/08, Timo Sirainen wrote:
On Feb 13, 2008, at 7:21 AM, Benjamin R. Haskell wrote:
On Wed, 13 Feb 2008, Rody wrote:
Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
Yes, but you may also care that ctime is reset when a client has
Dovecot move a message from one subfo
Bill Cole ha scritto:
(one can argue that HFS+ is Bad and Wrong in many ways, but it is in widespread
use...)
Widespread? On servers?
Well maybe would be nice to add a sort of warning to all apple sysadmin
out there in a evenctual future faq.
cheers
--
Andrea Perotti
smime.p7s
Descrip
At 12:21 AM -0500 2/13/08, Benjamin R. Haskell imposed structure on a stream
of electrons, yielding:
>On Wed, 13 Feb 2008, Rody wrote:
>>Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
>>>Yes, but you may also care that ctime is reset when a client has
>>>Dovecot move a message from one su
On 2/13/2008 Benjamin R. Haskell wrote:
Depends on the context for me. If it's in a spam folder, I'd rather
not keep it around any longer than it'd take for someone to say "Hey,
didn't you get that?". So -mtime +13 (2 weeks from receipt). (Thanks
for the heads-up on +13 vs. +14, btw).
Trash o
On Feb 13, 2008, at 7:21 AM, Benjamin R. Haskell wrote:
On Wed, 13 Feb 2008, Rody wrote:
Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
Yes, but you may also care that ctime is reset when a client has
Dovecot move a message from one subfolder to another within a
Maildir. I'm not sure w
On Wed, 13 Feb 2008, Rody wrote:
Op woensdag 13 februari 2008 00:43, schreef Bill Cole:
Yes, but you may also care that ctime is reset when a client has
Dovecot move a message from one subfolder to another within a
Maildir. I'm not sure why Dovecot does it, but a look at the messages
in the non-
From what i have seen, you're absolutely correct. It looks like the use of
ctime or mtime depends on wether you want the message removed x days after it
was moved to say the trash folder (ctime) or will be removed x days after it
originally arrived in the inbox (mtime). My personal opinion is c
At 10:45 PM +0100 2/12/08, Rody imposed structure on a stream of
electrons, yielding:
The opinions vary slightly when it comes to using mtime or ctime. I've chosen
ctime because i believe using mtime will not garantee that there aren't any
mails left which are actually older than 30 days. I be
excellent :)
thats good, I have used the same method to remove mail after my mail filter
learns it as spam now.
Everythings comming together nicley with my new dovecot server, althought the
server itself is still mostly in bits on the floor :)
Thanks,
Matt.
On Tue, Feb 12, 2008 at 10:45:08PM
On Tue, 12 Feb 2008, Rody wrote:
Funny, I asked a few days ago a similar question with the subject:
[Dovecot] replacement for IMAP_EMPTYTRASH=Trash:7
You may want to look for the responses to that question as it's essentially
the same.
For reference:
http://dovecot.org/list/dovecot/2008-Febru
Funny, I asked a few days ago a similar question with the subject:
[Dovecot] replacement for IMAP_EMPTYTRASH=Trash:7
You may want to look for the responses to that question as it's essentially
the same.
In short: you can do this with a find command to remove older mails. There
should be no issu
Hello,
I have dovecot running with MailDir as a backend to store email and I would
like to remove mail that is older that 30 days.
I can do this by running 'find' on the MailDir but will this cause any issues
with dovecot?
Thanks,
Matt.
--
Matt Richards
signature.asc
Description: Digital
26 matches
Mail list logo
