bugThe nmh Mail Handling System - Bugs: bug #56575, refile always hard links


bug #56575: refile always hard links

Submitted by:  None
Submitted on:  Wed 03 Jul 2019 02:16:59 AM UTC
Category:  Bug Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Fixed
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Sat 09 Apr 2022 07:53:19 PM UTC, comment #3: 

Fixed in commit 2e63b2d1966f42a1dc65d0c1d0cc3546fbbf4afd:
    Copy if hard link by refile(1) or send(1) fails with EACCES [Bug #56575].


    The bug was for refile(1) but send(1) can also try to hard link.

David Levine <levine>
Project Member
Tue 20 Oct 2020 01:08:12 PM UTC, comment #2: 

also came across this issue on termux
android gives linkerr errno 13 EACCES error when refile tries to create link
updating the if err check in folder_addmsg to include eacces fixed the issue and refile just copies the file
hope a new release includes some such fix

Wed 03 Jul 2019 03:50:17 PM UTC, comment #1: 

I can't reproduce this problem.

The documentation MAY be a bit misleading.  -link/-nolink really means, "Keep a link to the original message when refiling", it doesn't mean "use a specific system call".  But I use refile all of the time with a filesystem that does not support hard links and it works just fine.

folder_addmsg() (the function which ultimately does the work) will revert to a copy if the attempt to create a hard link fails with EXDEV, EISREMOTE, or EPERM. A quick Googling suggests that Termux fails hard link creation with EPERM, so we should do the right thing. It would be helpful if you could run the debugger on refile or report exactly what the failure message is.

Ken Hornstein <kenh>
Project Administrator
Wed 03 Jul 2019 02:16:59 AM UTC, original submission:  

refile fails on Termux -- essentially a modified Debian on Android.  Tracked it down to refile insisting on creating hard links, even with -nolink option.  Documentation suggests that option should cause refile to "mv", not "ln".  Even if this is the intended behavior (in which case the documentation isn't clear), hard links are not always available; there should be a flag for disabling their use altogether.

I tested using nmh 1.7.1~RC3-1build1 under Ubunto 18.04.1. Regardless of flags, refile created a hard link to the original message.  Works fine on my desktop -- but not on my Android tablet, requiring me to kluge a script to replace refile altogether.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by levine (Posted a comment)
  • -email is unavailable- added by kenh (Posted a comment)




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-04-09 levine StatusWorks For Me => Fixed
        Open/ClosedOpen => Closed
    2019-07-03 kenh StatusNone => Works For Me

    Back to the top

    Powered by Savane 3.9