From Fabrice.Rossi at apiacoa.org Tue Oct 1 11:59:05 2013 From: Fabrice.Rossi at apiacoa.org (Fabrice Rossi) Date: Tue, 01 Oct 2013 17:59:05 +0200 Subject: [Unison-hackers] Unison on a Synology DS412+ Message-ID: <524AF149.5010409@apiacoa.org> Hi, A short digression before the real subject: a huge thanks to all the unison developers for probably the most reliable software I've being using. As unison fits (almost) perfectly my needs for file synchronization, I've being trying to use it on my brand new nas, a Synology DS412+. I've experienced minor difficulties trying to compile and one part of the solution should probably be included into the sources, if I'm not mistaken. I include below a full description, hoping this might provide a good reference. All of this is tested with the current svn (revision 525, unison 2.46.20). 1) inotify As you might know, Synology's Nas are linux computers, but with some rather conservative versions of many things. In particular, they use the glibc 2.3.6 on the DS412+ (even with the brand new system!), which is a bit disturbing (and very very old). An annoying aspect of this version is that it does not include inotify support (it started in 2.4). As I'm very happy with unison 2.46.20 from the svn with the fsmonitor on my linux boxes, I really wanted to have inotify support. Unison sources include a work around for glibc prior 2.4 as fsmonitor/linux/inotify_stubs.c reads: #if __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 4 #define GLIBC_SUPPORT_INOTIFY 1 #else #define GLIBC_SUPPORT_INOTIFY 0 #endif #if GLIBC_SUPPORT_INOTIFY #include #else #include "inotify_compat.h" #endif Unfortunately, inotify-compat.h is not included in the svn repository. I've found a similar file in the ocaml-inotify repository https://github.com/vincenthz/ocaml-inotify, but for some reason, it does not compile on the DS412+. Probably a too old version of something. I was however successful with a comparable header from inotify-tools, here: https://github.com/rvoicilas/inotify-tools/blob/master/libinotifytools/src/inotifytools/inotify-nosys.h. So I would recommend to add to the svn repository something similar to this old glibc workaround. 2) native code With this file, unison compiles correctly, but in bytecode only as the ocaml compiler from the ipkg repository does not include ocamlopt. Recompiling a recent version of ocaml directly on the nas solves the problem but one has to specify manually a 32 bits architecture as the configure script seems to be confused by the peculiar Synology organization. So I had to use for ocaml 4.01: ./configure -cc "gcc -m32" -as "as --32" -aspp "gcc -m32 -c" -host i386-linux -partialld "ld -r -melf_i386" -prefix /opt prior make world.opt There are probably better options, but the default ones figured out by ./configure with a amd64 architecture does not work (the CPU is an Intel Atom D2701, so I'm puzzled). Anyway, after this build, make UISTYLE=text works perfectly, except some final errors related to etags (as I've not emacs installed on the nas, as far as I understand). 3) selftest A final note: while the obtained binary seems to work, selftest does not. More precisely, I've got: nas> ./unison -selftest Contacting server... Running internal tests... fastercheckUNSAFE 1... Test fastercheckUNSAFE 1 / 3b: Expected R2 = Dir [("x", File "f00")] but found Dir [("x", File "bar")] Fatal error: Self-test fastercheckUNSAFE 1 / 3b failed! Disturbingly, I've got the very same error on a standard ubuntu 12.04 box (here this is with ocaml 3.12.1). I'm probably doing something wrong. So if you set aside this selftest issue, everything seems to work perfectly. In particular, the fsmonitor works as expected, which is really great. I've not made any intensive tests, as I would like to have the opinion of the experts from this list on two things. Firstly is the inotify header I've been using a good solution? Secondly, what about this broken selftest on a perfectly standard ubuntu distro? Thanks in advance, Best, Fabrice PS: my caml knowledge is close to zero, by the way :-( From ikartur at gmail.com Thu Oct 24 09:13:38 2013 From: ikartur at gmail.com (=?UTF-8?Q?Ir=C3=A1nyossy_Knoblauch_Art=C3=BAr?=) Date: Thu, 24 Oct 2013 15:13:38 +0200 Subject: [Unison-hackers] [PATCH] Unison with eCryptfs Message-ID: Hi Everyone! Currently Unison will fail to sync files with more than 64 character long file names on systems using eCryptfs. Unison still has some trouble creating proper temporary file names on certain file systems which has some limitations on the maximum allowed file name length: for example, eCryptfs has a limitation of 143 characters long file names [1]. eCryptfs is widely used: for example the default Ubuntu installer offers you to encrypt your home folder using eCryptfs. If someone wants to use Unison on a system using encrypted home folders, Unison will highly likely fail to create temporary files. You can find users complaining about this in various places over the Internet ([2] [3] [4] [5]). A very similar problem related to temporary file name lengths was fixed in the past (where Unison tried to create temporary files with more than 256 characters long names). The approach was to crop file names to 64 characters and add an MD5 digest of the original file name to the temporary name. Using this method, if you have a file with 65 'a' characters Unison will fail to create a 148 characters long temporary file: .unison.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac743a45e0d2e6a95cb859adae0248435.0e30133d04f8d05f6556aa7ddc20ef74.unison.tmp I have created a patch that fixes this problem by ensuring that all temporary file names will be limited to exactly 143 characters. (The limit can be easily and safely modified). Please review it. Thank you very much, and have a nice day! ;-) References: [1] eCryptfs maximum file length: https://bugs.launchpad.net/ecryptfs/+bug/344878 [2] Unison fails to synchronize some git repositories: http://superuser.com/questions/629558/unison-fails-to-synchronize-some-git-repositories [3] Has Unison error on ?File name too long?: http://askubuntu.com/questions/232322/has-unison-error-on-file-name-too-long [4] File name too long (ecryptfs): http://groups.yahoo.com/neo/groups/unison-users/conversations/messages/10756 [5] long file names: http://groups.yahoo.com/neo/groups/unison-users/conversations/messages/10880 -------------- next part -------------- A non-text attachment was scrubbed... Name: limit_temp_file_names_to_be_compatible_with_eCryptfs.patch Type: text/x-patch Size: 1495 bytes Desc: not available URL: