maildir and ssh

maildir and ssh

[Adam W]

Hey,

I found a bug in gnus.  In mail-source.el, mail-source-fetch-dir there
is a call to delete-file.  Gnus checks this call to return non-nil.
When using a remote ssh maildir via ssh, delete-file returns nil though.

Here is the fixed function:

(defun mail-source-fetch-maildir (source callback)
  "Fetcher for maildir sources."
  (mail-source-bind (maildir source)
    (let ((found 0)
      mail-source-string)
      (unless (string-match "/$" path)
    (setq path (concat path "/")))
      (dolist (subdir subdirs)
    (when (file-directory-p (concat path subdir))
      (setq mail-source-string (format "maildir:%s%s" path subdir))
      (dolist (file (directory-files (concat path subdir) t))
        (when (and (not (file-directory-p file))
               (not (if function
                (funcall function file mail-source-crash-box)
                  (let ((coding-system-for-write
                     mm-text-coding-system)
                    (coding-system-for-read
                     mm-text-coding-system))
                (with-temp-file mail-source-crash-box
                  (insert-file-contents file)
                  (goto-char (point-min))
;;;               ;; Unix mail format
;;;               (unless (looking-at "\n*From ")
;;;                 (insert "From maildir "
;;;                     (current-time-string) "\n"))
;;;               (while (re-search-forward "^From " nil t)
;;;                 (replace-match ">From "))
;;;               (goto-char (point-max))
;;;               (insert "\n\n")
                  ;; MMDF mail format
                  (insert "\001\001\001\001\n"))
                (delete-file file)
                nil))))
          (incf found (mail-source-callback callback file))
          (mail-source-delete-crash-box)))))
      found)))

Any chance you could incorporate this in gnus?

Re: maildir and ssh

[Adam]

Adam W <adam_w67@yahoo.com> writes:

> Hey,
>
> I found a bug in gnus.  In mail-source.el, mail-source-fetch-dir there
> is a call to delete-file.  Gnus checks this call to return non-nil.
> When using a remote ssh maildir via ssh, delete-file returns nil though.
>
> Here is the fixed function:

[...]

>                 (delete-file file)
>                 nil))))

[...]

> Any chance you could incorporate this in gnus?

ping.  It's just that little nil that needs to be added...

Re: maildir and ssh

[Katsumi Yamaoka]

Adam W wrote:
> I found a bug in gnus.  In mail-source.el, mail-source-fetch-dir there
> is a call to delete-file.  Gnus checks this call to return non-nil.
> When using a remote ssh maildir via ssh, delete-file returns nil though.

> Here is the fixed function:
> (defun mail-source-fetch-maildir (source callback)

--- mail-source.el~	2011-04-05 05:00:09 +0000
+++ mail-source.el	2011-11-22 20:07:07 +0000
@@ -1038 +1038,2 @@
-				(delete-file file)))))
+				(delete-file file)
+				nil))))

I believe you're right, it's a mail-source bug.  Any Lisp code
should never expect the return value of `delete-file' since it
is not documented.  I verified it returns nil for a local file
but t for a remote file using ssh[1]:

(delete-file "/ssh:localhost:/home/yamaoka/FILE")

Fixed in the Gnus trunk and the Emacs trunk.

[1] Note that tramp runs "rm -f" (that is hard-coded) in a remote
system, so `delete-file' always returns t even if a file does not
exist.

Re: maildir and ssh

[Michael Albinus]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I believe you're right, it's a mail-source bug.  Any Lisp code
> should never expect the return value of `delete-file' since it
> is not documented.  I verified it returns nil for a local file
> but t for a remote file using ssh[1]:
>
> (delete-file "/ssh:localhost:/home/yamaoka/FILE")
>
> Fixed in the Gnus trunk and the Emacs trunk.
>
> [1] Note that tramp runs "rm -f" (that is hard-coded) in a remote
> system, so `delete-file' always returns t even if a file does not
> exist.

One could change Tramp to behave like plain `delete-file'. But since the
return value of `delete-file' is not documented ...

Best regards, Michael.