Lock files on NFS

[GoogleCodeExporter]

  I would like to change the location of lock files.
  Now the mozc creates the lock files under home directory. However it occurs a serious trouble for NFS users. Therefore I think that the lock files should be created, for example, under the /tmp directory on each host.

Original issue reported on code.google.com by yasu.sai...@gmail.com on 28 Dec 2014 at 3:39

[GoogleCodeExporter]

Thank you for the report.  This is one of known issues and currently 
$HOME/.mozc/ is not designed to be shareable with NFS. To work around this 
limitation, you might be able to replace $HOME/.mozc/ with a symlink to a 
different directory that is mounted into a local device.

I agree that Mozc for Linux should work without any user action even if $HOME 
is in NFS, but we don't have any specific target date or milestone to make it 
happen.

Thank you for your understanding.

Original comment by yukawa@google.com on 30 Dec 2014 at 12:55

• Changed state: VolunteersNeeded
• Added labels: Priority-Medium, OpSys-Linux
• Removed labels: Priority-Critical

[GoogleCodeExporter]

  Yukawa-san, I thank you for your very quick and precise advice. Great !
  Until now, I have used properly mozc (on emacs) and anthy (on ibus). From now on, I can just use the mozc uniformly.

  I created /tmp/userName/.mozc and put .server.lock and .session.ipc, and made these symbolic links in ~/.mozc.
  Perhaps it is just enough to link the /tmp/userName/.mozc to the home directory, however I think that I can NOT use my user dictionary on each host, or it must be necessary to synchronize the dictionaries all the hosts.

  Again, thank you for your information.

Original comment by yasu.sai...@gmail.com on 31 Dec 2014 at 2:02

[GoogleCodeExporter]

> it must be necessary to synchronize the dictionaries all the hosts.

I know some people are using some file-system level synchronization mechanisms 
such as NFS or dropbox to synchronize the user dictionaries and Mozc's settings 
among different machines.  That's nice, but please try it at your own risk.  It 
may or may not increase the risk of data corruption since we have designed Mozc 
so that basically only one process of mozc_server can update those files at the 
same time.  Of course, you can go beyond that assumption at your own risk, and 
it may or may not work, but again we haven't designed Mozc to be able to work 
appropriately when $USER/.mozc is shared among different machines and is 
accessed from different versions of mozc_server at the same time.

Hope this helps.

Original comment by yukawa@google.com on 31 Dec 2014 at 5:43