Re: File locking on sshfs file system, possible?
On Mon, Oct 28, 2019 at 07:29:52PM +, Chris Green wrote: > On Mon, Oct 28, 2019 at 01:31:57PM -0500, Derek Martin wrote: > > You're probably better off using (local) IMAP over SSH with your Mutt > > mailboxes. That is, you can ssh into your mail server and run imapd > > locally (rather than having it listen to incoming connections), and > > Mutt supports this. > > > I've never got on well with IMAP and mutt. But have you tried running it locally over SSH? There are a lot of factors that matter (and I admit I don't use it, but I don't really deal with attachments much), but when I tried it I found it was a very different animal than network-based IMAP. It has different performance tradeoffs and benefits/drawbacks. If you haven't tried it, I would highly encourage you to do so. You do still have to transfer your messages and attachments over SSH (but you were doing that anyway), but you do get to display them locally, which makes a lot of difference. Or can, depending on your exact usage patterns. I think it may get you most of what you want, and if so you may be able to throw away any hacking you've done to deal with your problem. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
On Mon, Oct 28, 2019 at 01:31:57PM -0500, Derek Martin wrote:
> On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote:
> > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main
> > mail directory ~/Mail using sshfs and running a local copy of mutt.
> > This makes handling attachments and HTML E-Mail much faster and easier
> > than running mutt on the remote system via ssh.
>
> SSHFS is a horrible hack (albeit a clever one that has many
> convenient uses). Unfortunately I've forgotten the details, but I
> know that several important file system semantics do not work
> with it, and IMO you should not use this for anything you consider
> important that needs reliability.
>
I've decided that sshfs isn't going to provide what I want.
> You're probably better off using (local) IMAP over SSH with your Mutt
> mailboxes. That is, you can ssh into your mail server and run imapd
> locally (rather than having it listen to incoming connections), and
> Mutt supports this.
>
I've never got on well with IMAP and mutt.
I've discovered that I can extend my existing hack/bodge/clever script
that I already use for viewing HTML mails using Firefox (when simply
using lynx isn't good enough).
What I do for HTML to Firefox is to have a script that is called
(using ~/.mailcap) to copy the HTML E-Mail to my web server's
DocumentRoot and then run Firefox to view the file. This works for a
remote 'connected by ssh' client as well as locally because Firefox
uses a remote Firefox to display the file. Thus I get to view the
HTML in a local Firefox (i.e. on the ssh client) and, as I have copied
the file back to the client (using rsync) it all works fast and locally.
What I then realised was that Firefox can view PDFs and JPGs and
similar so the same can be done for viewing PDF and JPG attachments
'locally' on the remote ssh client. It works too! :-)
My ~/.mailcap (on the machine where mutt is running) has:-
text/html; /home/chris/bin/muttfox %s
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
application/pdf; /home/chris/bin/muttfox %s
image/jpeg; /home/chris/bin/muttfox %s
... and the script muttfox is:-
#!/bin/bash
#
#
# muttfox: script called by mutt via mailcap to use firefox to view HTML,
and
# also some types attachments, currently:- PDF, JPG
#
# It is necessary for HTML files because /usr/bin/firefox exits
# before firefox has actually loaded the HTML file, this is especially
# true when it's remote but it also happens when running locally.
#
# It's not actually necessary for PDF and JPG files but it speeds up
# remote (i.e. running mutt via ssh) viewing considerably because it
# doesn't run the viewing program across the X connection. It works
# OK for local files so everything works the same.
#
# The temporary file to be viewed by Firefox is copied to directory
# /srv/mutt on esprimo if running locally or to the same place on the
# remote system if running via ssh. The copy to the remote system is
# done via an ssh reverse tunnel on port 50022 using a passwordless key
# and rrsync at the remote end to make it reasonably secure.
#
dir=/srv/mutt/
#
#
# if there's no DISPLAY variable then Firefox can't run, so skip the whole
thing
#
if [ -n "$DISPLAY" ]
then
chmod 0644 $1
if [ -n "$SSH_CLIENT" ]
then
rsync -e 'ssh -p 50022 -i /home/chris/.ssh/np_id_rsa' $1
localhost:$(basename $1)
else
cp $1 $dir$(basename $1)
fi
/usr/bin/firefox http://localhost/mutt/$(basename $1)
fi
#
#
# Clear out any old files left by this script, doing it here saves adding
# a special crontab task
#
find $dir -mtime +7 -exec rm {} \;
It works beautifully so now I can view PDF and other attachments
'fast' when I'm running mutt via ssh. I have to wait for the file to
copy but once that has happened scrolling, searching, etc. all work as
with a local file (which it is of course). It just relies on
Firefox's ability to view various file formats (or to find a program
that will do it).
--
Chris Green
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > mail directory ~/Mail using sshfs and running a local copy of mutt. > This makes handling attachments and HTML E-Mail much faster and easier > than running mutt on the remote system via ssh. SSHFS is a horrible hack (albeit a clever one that has many convenient uses). Unfortunately I've forgotten the details, but I know that several important file system semantics do not work with it, and IMO you should not use this for anything you consider important that needs reliability. You're probably better off using (local) IMAP over SSH with your Mutt mailboxes. That is, you can ssh into your mail server and run imapd locally (rather than having it listen to incoming connections), and Mutt supports this. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 10:42:28AM +0100, Chris Green wrote: mutt_dotlock is failing when I try and lock the file across the sshfs file system:- The last time I looked, sshfs's hard link support was insufficient for dotlocking. I believe the hard link count is not increased, (in addition to creating a new inode number for the link). Even if it were implemented, I personally wouldn't risk my mbox files over sshfs. Mutt 1.11.0 added a hard link fix for Maildir over sshfs. If you do try Maildir you'll want to either upgrade or disable hardlink support in the sshfs mount. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
October 25, 2019 5:42 PM, "Chris Green" wrote:
> Even more information!
>
> mutt_dotlock is failing when I try and lock the file across the
> sshfs file system:-
>
> chris@t470$ mutt_dotlock /home/chris/Mail/folder/test/fred
> chris@t470$ echo $?
> 1
> chris@t470$
>
> (The folder Mail is an sshfs mount)
>
> There is no permission problem for me to create files:-
>
> chris@t470$ ls -al /home/chris/Mail/folder/test
> total 8
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:38 .
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 ..
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:25 fred
> chris@t470$ touch /home/chris/Mail/folder/test/fred.lock
> chris@t470$ ls -al /home/chris/Mail/folder/test
> total 8
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:40 .
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 ..
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:25 fred
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:40 fred.lock
> `
> So how do I diagnose what the actual error is? Is mutt_dotlock trying
> to run as 'mail' rather than 'chris'?
I wonder if strace(1) could help you
('Cause it was suggested for finding Why Evince couldn't read files like
~/.mutt/file.pdf in this mailing list.)
--
旋转少女
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 10:14:28AM +0100, Chris Green wrote: > On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > > mail directory ~/Mail using sshfs and running a local copy of mutt. > > This makes handling attachments and HTML E-Mail much faster and easier > > than running mutt on the remote system via ssh. > > > > However when I try and save E-Mails into the ~/Mail hierarchy it > > complains that it can't lock the mbox file. I guess that there's some > > sort of incompatibility between mutt's default locking method and > > sshfs. > > > > Is there anything I can do about this? I.e. can I build mutt with a > > different locking method (or more the point the dotlock program I > > suppose) or am I basically stuck? I know I could move to maildir but > > I'd prefer not to really and that would likely slow things down across > > an sshfs connection. > > > A little more information:- > > I'm running mutt 1.10.1 on xubuntu 19.04 > > The actual error I'm seeing is "Couldn't lock > /home/chris/Mail/folder/test" > (Obviously changes according to name of destination mbox) > > So is it not a locking problem, rather a permission problem? My UID > on both systems is the same so files in the ~/Mail directory are all > owned by me on both systems. > Even more information! mutt_dotlock is failing when I try and lock the file across the sshfs file system:- chris@t470$ mutt_dotlock /home/chris/Mail/folder/test/fred chris@t470$ echo $? 1 chris@t470$ (The folder Mail is an sshfs mount) There is no permission problem for me to create files:- chris@t470$ ls -al /home/chris/Mail/folder/test total 8 drwxrwxr-x 1 chris chris 4096 Oct 25 10:38 . drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 .. -rw-rw-r-- 1 chris chris0 Oct 25 10:25 fred chris@t470$ touch /home/chris/Mail/folder/test/fred.lock chris@t470$ ls -al /home/chris/Mail/folder/test total 8 drwxrwxr-x 1 chris chris 4096 Oct 25 10:40 . drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 .. -rw-rw-r-- 1 chris chris0 Oct 25 10:25 fred -rw-rw-r-- 1 chris chris0 Oct 25 10:40 fred.lock ` So how do I diagnose what the actual error is? Is mutt_dotlock trying to run as 'mail' rather than 'chris'? -- Chris Green
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > mail directory ~/Mail using sshfs and running a local copy of mutt. > This makes handling attachments and HTML E-Mail much faster and easier > than running mutt on the remote system via ssh. > > However when I try and save E-Mails into the ~/Mail hierarchy it > complains that it can't lock the mbox file. I guess that there's some > sort of incompatibility between mutt's default locking method and > sshfs. > > Is there anything I can do about this? I.e. can I build mutt with a > different locking method (or more the point the dotlock program I > suppose) or am I basically stuck? I know I could move to maildir but > I'd prefer not to really and that would likely slow things down across > an sshfs connection. > A little more information:- I'm running mutt 1.10.1 on xubuntu 19.04 The actual error I'm seeing is "Couldn't lock /home/chris/Mail/folder/test" (Obviously changes according to name of destination mbox) So is it not a locking problem, rather a permission problem? My UID on both systems is the same so files in the ~/Mail directory are all owned by me on both systems. -- Chris Green
