On Wed, 29 Feb 2012 15:40:27 +0100
Prefer Anon <my.m...@gmail.com> wrote:
| Thanks Greg that was the first idea I had but then it occurred to me that
| for Unison to compare my homedir with the local plaintext copy it actually
| has to read over the plaintext copy. But the local plaintext is just a
| non-encrypted version of the remote mount which means its actually remote
| and so very slow to read. Unison trying to scan over this file would
| basically lose all the advantages of unison which is to have a copy run on
| the server to avoid any the huge network overhead of rereading the files.
| It might be that unison can get away with just reading the timestamps and
| so only have to read the files that change which might not be too bad. But
| this still seems like a somewhat unideal solution from that perspective.
|
Unison will nto read or checksum a file if the file has nto changed size
of date stamp. so the benifit is still their (though initialization can
take a long time).
however if unison is only applied to already synced data, or between two
machines which only store encrypted data (as my second simplified case)
than their is no problem unison is dealing with actual data files
(encrypted though they are).
The only time you may have sever disadvantages is if the file system
unison is reading from is not real (IE a network mount of some kind)
and then typically only for the initial run while unison creates its
checksum cache.
That is best avoided.
encfs is a full filesystem and if the underlying system can handle disk
block reads (can sshfs do block reads?), encfs will work efficiently with
that file system.
Remote file sync systems (like dropbox) typically do keep a local copy
of the files being sync'ed, so those files can be used when the machine
is disconnected from the network. Basically they do the job of unison.
And in that case it is probably best to keep the files encrypted (as it
is on the remote server) and mount an un-encrypted version via enc-fs
of the local sync, when you need to look at or working on those files.
NOTE: encfs does not even need to keep the .encfs6-config with the
encrypted data. Of course any machine that you want to be able to
decrypt the data much have a copy of this config.
ENCFS6_CONFIG="encfs_config_file" encfs /tmp/encfs_dir /tmp/decoded_dir
That is keep the encryption information separate to the encrypted data that
is stored on the remote server.
Also note that encfs only reads that file once! as such you can make this
a fifo pipeline file, and feed the config file from some other locked source!
I myself do this using a system I call "key store" or "ks" where the
user password unlocks a encrypted file containing the real password of
the encfs partition and the config data file. This allows me to
change the 'password' to lock the encfs data, any time I like, or even
have multiple passwords.
Anthony Thyssen ( System Programmer ) <a.thys...@griffith.edu.au>
--------------------------------------------------------------------------
Can not say. Saying, would know. Do not know, so can not say!
-- Zatheris, Bablyon 5, "War Without End"
--------------------------------------------------------------------------
Anthony's Castle http://www.ict.griffith.edu.au/anthony/
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users
