| 1 |
Neil Bothwick <neil@××××××××××.uk> writes: |
| 2 |
|
| 3 |
> On Wed, 06 Jan 2010 15:27:32 -0600, Harry Putnam wrote: |
| 4 |
> |
| 5 |
>> > Then use rsync instead of tar, then you can mount the remote |
| 6 |
>> > filesystem using sshfs and encfs to read individual files. It's a |
| 7 |
>> > little slow as you are layering two FUSE filesystems, but quicker |
| 8 |
>> > than downloading a complete tarball just to get at one file. I've |
| 9 |
>> > used this method with an online backup service and it works. |
| 10 |
>> |
| 11 |
>> Neil seems to be thinking the remote has encfs on board... it does |
| 12 |
>> not. Hence my original quest for a different encryption process, |
| 13 |
>> (mcrypt) |
| 14 |
> |
| 15 |
> I wasn't thinking that at all. You use sshfs to mount the remote |
| 16 |
> directory locally, then mount that with encfs. All the remote host needs |
| 17 |
> is ssh. |
| 18 |
|
| 19 |
I'm not sure what is going wrong here, if neither of us is listening |
| 20 |
to the other or what... but I've stressed that I wanted a solution for |
| 21 |
when I could not access my home machine.... Does your solution involve |
| 22 |
that? |
| 23 |
|
| 24 |
Expecting to work out encfs and sshfs/fuse etc on a session in the |
| 25 |
nearest kinkos, probably on machines running one or another version of |
| 26 |
windows, and further with no download or install options on said |
| 27 |
machine is not all that nifty of an approach. |
Archives