I installed unixmail-w32 without any apparent problems. When I start mutt, however, I get
Reading g:/mail/davidm/spool...
for several seconds, then I get
Lock count exceeded, remove lock for
g:/mail/davidm/spool? ([y]/n):
I get this every time -- even if I remove the lock. I also get a similar problem with mutt_dotlock as this exchange demonstrates...
davidm@MANGO:/tmp $ rm foo*
rm: cannot remove `foo*': No such file or directory
davidm@MANGO:/tmp $ touch foo
davidm@MANGO:/tmp $ mutt_dotlock foo; echo $?
3
While mutt_dotlock runs, I see foo.lock and foo.MANGO.### being created. After mutt_dotlock exits with return value 3, the foo.lock file remains and can be removed with "mutt_dotlock -u foo". It seems that it is succeeded in locking the file, but it somehow thinks that it didn't.
Does anyone know what could be wrong? I really want to get mutt running under windows so I can have a consistent email client between Linux and windows.
Thanks,
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I finally tracked down the problem. It seems that mutt_dotlock creates an NFS lock file (e.g. foo.<hostname>.<pid>), tries to hard link the lock file (e.g. foo.lock) to the NFS lock file, and then checks whether the number of hard links to the NFS lock file is 2 (indicating successful locking).
Unfortunately, FAT filesystems do not support hard links. To work around this limitation of FAT filesystems, Cygwin performs a copy instead of a link. The Cygwin User's Guide (http://cygwin.com/cygwin-ug-net/highlights.html#OV-HI-FILES) says this is "a strategy that works in many cases". This is one of the cases where it doesn't work. :-(
Not surprisingly, this means that the hard link count will never exceed one which means that mutt_dotlock will never think that the lock was successfully created (even if it was).
I have created a workaround that seems to work on my system. If anyone is interested, let me know and I'll share all of the (not terribly) gory details.
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed unixmail-w32 without any apparent problems. When I start mutt, however, I get
Reading g:/mail/davidm/spool...
for several seconds, then I get
Lock count exceeded, remove lock for
g:/mail/davidm/spool? ([y]/n):
I get this every time -- even if I remove the lock. I also get a similar problem with mutt_dotlock as this exchange demonstrates...
davidm@MANGO:/tmp $ rm foo*
rm: cannot remove `foo*': No such file or directory
davidm@MANGO:/tmp $ touch foo
davidm@MANGO:/tmp $ mutt_dotlock foo; echo $?
3
While mutt_dotlock runs, I see foo.lock and foo.MANGO.### being created. After mutt_dotlock exits with return value 3, the foo.lock file remains and can be removed with "mutt_dotlock -u foo". It seems that it is succeeded in locking the file, but it somehow thinks that it didn't.
Does anyone know what could be wrong? I really want to get mutt running under windows so I can have a consistent email client between Linux and windows.
Thanks,
Dave
I finally tracked down the problem. It seems that mutt_dotlock creates an NFS lock file (e.g. foo.<hostname>.<pid>), tries to hard link the lock file (e.g. foo.lock) to the NFS lock file, and then checks whether the number of hard links to the NFS lock file is 2 (indicating successful locking).
Unfortunately, FAT filesystems do not support hard links. To work around this limitation of FAT filesystems, Cygwin performs a copy instead of a link. The Cygwin User's Guide (http://cygwin.com/cygwin-ug-net/highlights.html#OV-HI-FILES) says this is "a strategy that works in many cases". This is one of the cases where it doesn't work. :-(
Not surprisingly, this means that the hard link count will never exceed one which means that mutt_dotlock will never think that the lock was successfully created (even if it was).
I have created a workaround that seems to work on my system. If anyone is interested, let me know and I'll share all of the (not terribly) gory details.
Dave