[PATCH] Ignore trailing slashes for folder names with header cache

Hi,

with maildir mutt's tab-completion is not optimal as it automatically 
adds a trailing slash. This leads to different md5 sums (in case one db 
file per folder is used) and to different keys for the messages.

The latter makes it a little more complicated to ignore the slash 
because the same md5 sum isn't enough because the key is different.

Attached is a patch which should work for all hcache modules.

The patch doesn't really conform to mutt coding style as does hcache.c 
in many more places...

   bye, Rocco
--

-- 
:wq!

diff --git a/hcache.c b/hcache.c
index 0974600..db80da1 100644
--- a/hcache.c
+++ b/hcache.c
@@ -769,14 +769,25 @@ #elif HAVE_GDBM
 #endif
 }

+static char* get_foldername(const char *folder) {
+  size_t flen = mutt_strlen (folder);
+  char* p = safe_strdup(folder);

Re: [PATCH] Ignore trailing slashes for folder names with header

Applied, thanks.

On Monday, 02 October 2006 at 11:21, Rocco Rutte wrote:
> Hi,
> 
> with maildir mutt's tab-completion is not optimal as it automatically 
> adds a trailing slash. This leads to different md5 sums (in case one db 
> file per folder is used) and to different keys for the messages.
> 
> The latter makes it a little more complicated to ignore the slash 
> because the same md5 sum isn't enough because the key is different.
> 
> Attached is a patch which should work for all hcache modules.
> 
> The patch doesn't really conform to mutt coding style as does hcache.c 
> in many more places...
> 
>   bye, Rocco

Re: [PATCH] Clear progress bar when done

Applied, thanks.

On Saturday, 30 September 2006 at 10:01, Rocco Rutte wrote:
> Hi,
> 
> it's just a minor issue: mutt doesn't clear the progress bar when it's 
> done fetching something. For example, if it fetches a 100k message it 
> properly displays the bar with incremental updates. If all messages 
> afterwards are smaller than $net_inc, mutt won't update the status line 
> and leave the last incremental update until a message is seen which is 
> larger than $net_inc.
> 
> This can make the user think that mutt is hanging while fetching the 
> message though it actually doesn't.
> 
> The attached patch clears the status line if the current progress' bar 
> position is equal to or larger than the total size to be fetched.
> 
>   bye, Rocco

mutt_adv_mktemp() ?

Hi,

why would mutt_adv_mktemp() start creating temp files with '.z' at the end ?
I tried to open the mailbox with this message in a debugging session, but
works ok there, and I can't hook a debugger to this running process....
Is this a fluke decision of mktemp(3C) ? I don't have nametemplate in the
mailcap file:

text/html;  w3m-m17n -dump -I %{charset} -T text/html -m %s; copiousoutput

This is Solaris 9, mutt 1.4.2.1i

Thanks !
    Pawel.

----- Forwarded message from Tony Donile  -----

[-- Autoview: using w3m-m17n -dump -I 'ISO-8859-1' -T text/html -m '/tmp/mutt06aO.z' --]

gunzip: stdin: not in gzip format

----- End forwarded message -----

[2006-10-04] CVS repository changes

This message was generated and sent automatically.  It contains a
summary of the CVS commits over the last 48 hours.  These changes
should be propagated to the public repository within at most a day
or two.  Most probably, they have already been propagated.

2006-10-03 16:45:45  Rocco Rutte  <pdmef <at> gmx.net>  (brendan)

	* curs_lib.c: Clear the progress bar when the current operation
	has completed.

	* hcache.c: Ignore trailing slashes in folder names when mapping
	to header cache.

Re: mutt_adv_mktemp() ?

Hi,

* Pawel S. Veselov [06-10-03 13:46:56 -0700] wrote:

>why would mutt_adv_mktemp() start creating temp files with '.z' at the end ?

By default it asks the system to create 'muttXXXXXX' and make it replace 
'XXXXXX' with some random sequence so that the resulting file doesn't 
exist yet.

In your case 'XXXXXX' is replaced by '06a0.z'.

>I don't have nametemplate in the
>mailcap file:

The nametemplate should be used. The only effect is that mutt adds the 
extension on its own because mktemp() and mkstemp() cannot replace a 
sequence within a string but only at the end (...which is why we cannot 
use mkstemp() all over the place).

It's bad coinsidence that '.z' in the random part can by considered an 
extension by humans (or machines). I'm not sure, but a wild guess is 
that elinks thinks by '.z' 'extension' it's a compressed file which 
isn't true in this case... Using the nametemplate should be fine.

   bye, Rocco
--

-- 
:wq!

Re: mutt_adv_mktemp() ?

=- Rocco Rutte wrote on Wed  4.Oct'06 at  7:45:34 +0000 -=

> >I don't have nametemplate in the mailcap file:
>
> It's bad coinsidence that '.z' in the random part can by
> considered an extension by humans (or machines). I'm not sure,
> but a wild guess is that elinks thinks by '.z' 'extension' it's
> a compressed file which isn't true in this case... Using the
> nametemplate should be fine.

If your app can read data from STDIN (as the err-msg seems to
indicate), drop %s altogether and let it read from STDIN instead
(see wiki-faq lynx-example). This saves you from potential
conflicts and extra tmp-files.

--

-- 
© Rado S. -- You must provide YOUR effort for your goal!
Even if it seems insignificant, in fact EVERY effort counts
for a shared task, at least to show your deserving attitude.

Re: mutt_adv_mktemp() ?

On Wednesday, October  4 at 07:45 AM, quoth Rocco Rutte:
> The nametemplate should be used. The only effect is that mutt adds 
> the extension on its own because mktemp() and mkstemp() cannot 
> replace a sequence within a string but only at the end (...which is 
> why we cannot use mkstemp() all over the place).

Two points:

1. For extensions, there is mkstemps(), though it is slightly less 
portable.

2. More portably, what's wrong with:

    char tmpfile[POSIX_PATH_MAX] = "/tmp/muttXXXXXX";
    char tmpfile2[POSIX_PATH_MAX];
    char *extension = "foo";
    sprintf(tmpfile2, "%s.%s", tmpfile, extension);
    fd = mkstemp(tmpfile);
    rename(tmpfile, tmpfile2);

~Kyle
--

-- 
Most truths are so naked that people feel sorry for them and cover 
them up, at least a little bit.
                                                   -- Edward R. Murrow

Re: mutt_adv_mktemp() ?

Hi,

* Kyle Wheeler [06-10-04 10:26:52 -0400] wrote:
>On Wednesday, October  4 at 07:45 AM, quoth Rocco Rutte:a

>>The nametemplate should be used. The only effect is that mutt adds the extension on its own because
mktemp() and mkstemp() cannot replace a sequence within a string but 
>>only at the end (...which is why we cannot use mkstemp() all over the place).

>Two points:

>1. For extensions, there is mkstemps(), though it is slightly less portable.

Still someone needs to hack support for it including a configure test.

>2. More portably, what's wrong with:

>   char tmpfile[POSIX_PATH_MAX] = "/tmp/muttXXXXXX";
>   char tmpfile2[POSIX_PATH_MAX];
>   char *extension = "foo";
>   sprintf(tmpfile2, "%s.%s", tmpfile, extension);
>   fd = mkstemp(tmpfile);
>   rename(tmpfile, tmpfile2);

Without any reading, I'm not sure if it's a good idea to rename() a file 
which is already open. But you still can have races between the test for 
the existence of the new file and the actual rename and thus loose data.

   bye, Rocco
--

-- 

Re: mutt_adv_mktemp() ?

On Wed, Oct 04, 2006 at 10:26:52AM -0400, Kyle Wheeler wrote:

> 2. More portably, what's wrong with:

It would seem to kind of defeat the purpose of calling a function to
generate a unique filename...

--

-- 
Paul