[mu4e bug] mu4e-view-save-attachments directly overwrite files with the same name #2090
Closed
3 tasks
Comments
|
sdycjsj ***@***.***> writes:
Describe the bug
The function to save attachment in the new gnus view, mu4e-view-save-attachments, does not offer to change file name etc. when file with the same name exists, and just overwrite it.
To Reproduce
Open an email with an attachment; save the attachment; save for a
second time.
Is something like this working for you?
```
(defun mu4e-view-save-attachments (&optional arg)
"Save mime parts from current mu4e gnus view buffer.
When helm-mode is enabled provide completion on attachments and
possibility to mark candidates to save, otherwise completion on
attachments is done with `completing-read-multiple', in this case
use \",\" to separate candidate, completion is provided after
each \",\".
Note, currently this does not work well with file names
containing commas."
(interactive "P")
(cl-assert (and (eq major-mode 'mu4e-view-mode)
(derived-mode-p 'gnus-article-mode)))
(let* ((parts (mu4e~view-gather-mime-parts))
(handles '())
(files '())
(compfn (if (and (boundp 'helm-mode) helm-mode)
#'completing-read
;; Fallback to `completing-read-multiple' with poor
;; completion
#'completing-read-multiple))
dir)
(dolist (part parts)
(let ((fname (cdr (assoc 'filename (assoc "attachment" (cdr part))))))
(when fname
(push `(,fname . ,(cdr part)) handles)
(push fname files))))
(if files
(progn
(setq files (let ((helm-comp-read-use-marked t))
(funcall compfn "Save part(s): " files))
dir (if arg (read-directory-name "Save to directory: ") mu4e-attachment-dir))
(cl-loop for (f . h) in handles
when (member f files)
do (mm-save-part-to-file
h (let ((file (expand-file-name f dir)))
(if (file-exists-p file)
(let (newname
(count 1))
(while (progn
(setq newname (concat (file-name-sans-extension file)
(format "(%s)" count)
(file-name-extension file t)))
(file-exists-p newname))
(cl-incf count))
newname)
file)))))
(mu4e-message "No attached files found"))))
```
…--
Thierry
|
|
I think simply replace |
|
"Dirk-Jan C. Binnema" ***@***.***> writes:
I think simply replace mm-save-part-to-file with mm-save-part should do the trick, or?
Isn't mm-save-part asking for a filename? If so it would be an annoyance
and defeat the purpose of completion.
The attached function in previous mail is creating numbered copy of file
e.g. when saving foo.txt and foo.txt already exists it will save
attached file foo.txt as foo(1).txt, if you save again same attachment,
it will be saved as foo(2).txt and so on, these without asking.
…--
Thierry
|
thierryvolpiatto
added a commit
to thierryvolpiatto/mu
that referenced
this issue
Aug 16, 2021
|
I think this is a good solution. Thanks. |
|
I prefer the latter behavior, that's also consistent with what |
|
"Dirk-Jan C. Binnema" ***@***.***> writes:
I prefer the latter behavior, that's also consistent with wath A <n> s does (and similar to the old-viewer behavior).
Note that attached files with same name are not necessarily the same
file.
With the old behavior, when the attachment file foo.txt already exists,
you have two alternatives (yes or no), _yes_ to overwrite the existing
file and _no_ to do nothing and keep the old file.
Most modern apps like browsers are saving files as foo(1).txt etc...
…--
Thierry
|
|
In my use case, in the old viewer, when file with the same name exists and I choose not to overwrite, I am brought back to edit the file name. Btw, I use ivy. A bit of off topic, talking about ivy, with ivy and the new gnus viewer, there is no candidate to complete when saving attachments. Manually inputting some leading letters and hitting TAB works though. |
|
sdycjsj ***@***.***> writes:
In my use case, in the old viewer, when file with the same name exists
and I choose not to overwrite, I am brought back to edit the file
name.
Yeah, it is a pain to have to edit filenames, better off auto renaming
with numbered backup names.
Btw, I use ivy.
A bit of off topic, talking about ivy, with ivy and the new gnus
viewer, there is no candidate to complete when saving
attachments.
With Helm you have completion on all candidates and you can mark only
the ones you want to save, with other backends Ivy etc... mu4e uses a
completing-read-multiple where you have completion with TAB and you can
separate candidates with comma.
…--
Thierry
|
|
Merged the commit -- thanks! TBH, it's not my perfect solution, ideally I think mu4e should check whether the file is the same as the to-be-written file, and only in the rare case they're not the same, warn user. Some other day! Anyway, numbering them at least avoid overwriting for now, so it is an improvement. |
djcb
added a commit
that referenced
this issue
Aug 21, 2021
…ttachments Create numbered backup of attached file when already exists #2090
|
"Dirk-Jan C. Binnema" ***@***.***> writes:
Merged the commit -- thanks!
TBH, it's not my perfect solution, ideally I think mu4e should check
whether the file is the same as the to-be-written file,
It can be tested easily with `file-equal-p`.
and only in the rare case they're not the same, warn user.
Not so rare, in many agency (immo, admin etc...) they have often bad
pratices with filenames (and computing more generaly), e.g. you can
receive ATTESTATION.pdf, LOYER.pdf or even worst DOCUMENT.pdf every
month from some agencies, of course the file is always a different one.
Some other day!
Yes! If I have a better idea I will make a PR.
Thanks.
…--
Thierry
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The function to save attachment in the new gnus view,
mu4e-view-save-attachments, does not offer to change file name etc. when file with the same name exists, and just overwrite it.To Reproduce
Open an email with an attachment; save the attachment; save for a second time.
Environment
Macos, Emacs 28, mu/mu4e 1.6.3
Checklist
The text was updated successfully, but these errors were encountered: