We've been using MacFuse for a long time with EncFS, on multiple
machines.
It's never given me any problems. (on 32 bit machines with both
Leopard and Snow Leopard).
However, we've recently added a few new machines. They come standard
with Snow Leopard and 64 bit enabled now.
On the 64bit machines, it seems the images are regularly unmounted
without notice.
I wrote a small script that can reproduce quite fast.
It doesn't do much, it just continuously creates new directories and
touches (creates) files in them.
This works fine for a long time, but after a while, the 'touch' seems
to take very long, and eventually 'times out' with the error:
Socket is not connected.
At this point, the drive is no longer mounted.
(mount doesn't display it anymore, mountpoint directory inode is no
longer the same as the data directory inode)
It just disappeared....
I looked at the logs in Console.app, and in /var/log/syslog, but
nothing is added in there.
In dmesg, I do see fuse references, but nothing that points to a bug/
crash.
Is this a known problem? Is there a fix/workaround?
Where should I look for more logging?
Is this a MacFuse error, or is this specific to EncFS and should I
report a bug there?
Do you guys use 64bit macs? Have you encountered the same problems?
If you're using one of the early 64-bit builds that didn't have some of the checks in place then it is entirely possible there is an access issue that is happening behind the scenes with the requests that is resulting in something getting terminated. What version of 64-bit compatible MacFUSE are you using?
When you get the socket not connected, does the encfs process still live on? Have you looked for any crash reporter files? It could be a bug in encfs as well, I've had incorrectly built semaphore code (*cough* e.g. my own) result in a state where the process gets terminated because the number of requests hitting it simultaneously overloaded the implementation and resulted in a failure.
On Thu, Jun 23, 2011 at 11:32 PM, Kenny <psyki...@gmail.com> wrote: > Hi,
> We've been using MacFuse for a long time with EncFS, on multiple > machines. > It's never given me any problems. (on 32 bit machines with both > Leopard and Snow Leopard). > However, we've recently added a few new machines. They come standard > with Snow Leopard and 64 bit enabled now.
> On the 64bit machines, it seems the images are regularly unmounted > without notice. > I wrote a small script that can reproduce quite fast. > It doesn't do much, it just continuously creates new directories and > touches (creates) files in them. > This works fine for a long time, but after a while, the 'touch' seems > to take very long, and eventually 'times out' with the error:
> Socket is not connected.
> At this point, the drive is no longer mounted. > (mount doesn't display it anymore, mountpoint directory inode is no > longer the same as the data directory inode)
> It just disappeared.... > I looked at the logs in Console.app, and in /var/log/syslog, but > nothing is added in there. > In dmesg, I do see fuse references, but nothing that points to a bug/ > crash.
> Is this a known problem? Is there a fix/workaround? > Where should I look for more logging? > Is this a MacFuse error, or is this specific to EncFS and should I > report a bug there?
> Do you guys use 64bit macs? Have you encountered the same problems?
> -- > You received this message because you are subscribed to the Google Groups "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/macfuse?hl=en.
The Preference pane tells me that the version installed in 2.1.9 ()
To my knowledge this is still the latest (semi-stable) version that
supports 64-bit?
Is there another version I should try out?
When MacFuse is unmounted (crashed), the encfs process is gone too.
> If you're using one of the early 64-bit builds that didn't have some
> of the checks in place then it is entirely possible there is an access
> issue that is happening behind the scenes with the requests that is
> resulting in something getting terminated. What version of 64-bit
> compatible MacFUSE are you using?
> When you get the socket not connected, does the encfs process still
> live on? Have you looked for any crash reporter files? It could be a
> bug in encfs as well, I've had incorrectly built semaphore code
> (*cough* e.g. my own) result in a state where the process gets
> terminated because the number of requests hitting it simultaneously
> overloaded the implementation and resulted in a failure.
> On Thu, Jun 23, 2011 at 11:32 PM, Kenny <psyki...@gmail.com> wrote:
> > Hi,
> > We've been using MacFuse for a long time with EncFS, on multiple
> > machines.
> > It's never given me any problems. (on 32 bit machines with both
> > Leopard and Snow Leopard).
> > However, we've recently added a few new machines. They come standard
> > with Snow Leopard and 64 bit enabled now.
> > On the 64bit machines, it seems the images are regularly unmounted
> > without notice.
> > I wrote a small script that can reproduce quite fast.
> > It doesn't do much, it just continuously creates new directories and
> > touches (creates) files in them.
> > This works fine for a long time, but after a while, the 'touch' seems
> > to take very long, and eventually 'times out' with the error:
> > Socket is not connected.
> > At this point, the drive is no longer mounted.
> > (mount doesn't display it anymore, mountpoint directory inode is no
> > longer the same as the data directory inode)
> > It just disappeared....
> > I looked at the logs in Console.app, and in /var/log/syslog, but
> > nothing is added in there.
> > In dmesg, I do see fuse references, but nothing that points to a bug/
> > crash.
> > Is this a known problem? Is there a fix/workaround?
> > Where should I look for more logging?
> > Is this a MacFuse error, or is this specific to EncFS and should I
> > report a bug there?
> > Do you guys use 64bit macs? Have you encountered the same problems?
> > --
> > You received this message because you are subscribed to the Google Groups "MacFUSE" group.
> > To post to this group, send email to macfuse@googlegroups.com.
> > To unsubscribe from this group, send email to macfuse+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/macfuse?hl=en.
i also have the exact same issue on 64bit with 2.1.9 ..
but it effects my shutdown and i watch it in verbose mode and it seems its a recursive loop preventing the machine from full shut down... it was working fine the past few months so im not sure if it was an apple update that caused this or 3rd party software i did just install VMware so that might be a cause as well...
On Fri, Jun 24, 2011 at 1:38 AM, Kenny <psyki...@gmail.com> wrote: > Hello, thanks for the quick response.
> The Preference pane tells me that the version installed in 2.1.9 () > To my knowledge this is still the latest (semi-stable) version that > supports 64-bit? > Is there another version I should try out?
> When MacFuse is unmounted (crashed), the encfs process is gone too.
> In case it helps, this is the output from dmesg:
> On Jun 23, 5:13 pm, Sam Moffatt <pasa...@gmail.com> wrote: > > If you're using one of the early 64-bit builds that didn't have some > > of the checks in place then it is entirely possible there is an access > > issue that is happening behind the scenes with the requests that is > > resulting in something getting terminated. What version of 64-bit > > compatible MacFUSE are you using?
> > When you get the socket not connected, does the encfs process still > > live on? Have you looked for any crash reporter files? It could be a > > bug in encfs as well, I've had incorrectly built semaphore code > > (*cough* e.g. my own) result in a state where the process gets > > terminated because the number of requests hitting it simultaneously > > overloaded the implementation and resulted in a failure.
> > On Thu, Jun 23, 2011 at 11:32 PM, Kenny <psyki...@gmail.com> wrote: > > > Hi,
> > > We've been using MacFuse for a long time with EncFS, on multiple > > > machines. > > > It's never given me any problems. (on 32 bit machines with both > > > Leopard and Snow Leopard). > > > However, we've recently added a few new machines. They come standard > > > with Snow Leopard and 64 bit enabled now.
> > > On the 64bit machines, it seems the images are regularly unmounted > > > without notice. > > > I wrote a small script that can reproduce quite fast. > > > It doesn't do much, it just continuously creates new directories and > > > touches (creates) files in them. > > > This works fine for a long time, but after a while, the 'touch' seems > > > to take very long, and eventually 'times out' with the error:
> > > Socket is not connected.
> > > At this point, the drive is no longer mounted. > > > (mount doesn't display it anymore, mountpoint directory inode is no > > > longer the same as the data directory inode)
> > > It just disappeared.... > > > I looked at the logs in Console.app, and in /var/log/syslog, but > > > nothing is added in there. > > > In dmesg, I do see fuse references, but nothing that points to a bug/ > > > crash.
> > > Is this a known problem? Is there a fix/workaround? > > > Where should I look for more logging? > > > Is this a MacFuse error, or is this specific to EncFS and should I > > > report a bug there?
> > > Do you guys use 64bit macs? Have you encountered the same problems?
> > > -- > > > You received this message because you are subscribed to the Google > Groups "MacFUSE" group. > > > To post to this group, send email to macfuse@googlegroups.com. > > > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > > > For more options, visit this group athttp:// > groups.google.com/group/macfuse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
Hello, I'm still struggling with this, but found a bit more logging
(still not much I'm afraid) using the -v (verbose) and -d (debug)
options of both MacFuse and EncFS.
Any suggestions where I might find more? Or do any of you see any
fatal errors in this logging?
So, my test script basically just continuously creates files (touch
command), on a MacFuse drive with the EncFS filesystem.
The test script output:
...
Creating file no 7917
Creating file no 7918
Creating file no 7919
touch: /tmp/mount/random-dir-7/random-file.7919: Socket is not
connected
Before the error pops up, there is a long time where nothing happens
and everything seems to hang (timeout?)
Output from MacFuse/Encfs: (encfs lines start with timestamp, MacFuse
output does not):
(note that the file with name 7918 worked properly, it fails when
attempting to create the file with name 7919)
The ''No such file or directory" seem normal to me, as they also
appear in all other (correctly created) files.
MKNOD /random-dir-7/random-file.7918
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1: No
such file or directory
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
13721226668822013149, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, mode 33188, dev 0
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
13721226668822013149, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
NODEID: 67926
unique: 0, error: 0 (Unknown error: 0), outsize: 152
unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 59
LOOKUP /random-dir-7/._random-file.7918
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
such file or directory
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
13170079601340108218, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
such file or directory
16:52:23 (encfs.cpp:138) getattr error: No such file or directory
unique: 1, error: -2 (No such file or directory), outsize: 16
unique: 0, opcode: GETATTR (3), nodeid: 67926, insize: 40
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
13721226668822013149, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
unique: 0, error: 0 (Unknown error: 0), outsize: 128
unique: 1, opcode: OPEN (14), nodeid: 67926, insize: 48
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
13721226668822013149, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
16:52:23 (RawFileIO.cpp:129) open call for writable file
16:52:23 (RawFileIO.cpp:151) open file with flags 2, result = 4
16:52:23 (encfs.cpp:573) encfs_open for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, flags
1
unique: 1, error: 0 (Unknown error: 0), outsize: 32
OPEN[40346368] flags: 0x1 /random-dir-7/random-file.7918
unique: 0, opcode: FLUSH (25), nodeid: 67926, insize: 64
FLUSH[40346368]
16:52:23 (encfs.cpp:134) flush /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
16:52:23 (RawFileIO.cpp:129) open call for read only file
16:52:23 (RawFileIO.cpp:136) using existing file descriptor
unique: 0, error: 0 (Unknown error: 0), outsize: 16
unique: 1, opcode: RELEASE (18), nodeid: 67926, insize: 64
RELEASE[40346368] flags: 0x1
unique: 1, error: 0 (Unknown error: 0), outsize: 16
unique: 0, opcode: LOOKUP (1), nodeid: 60008, insize: 57
LOOKUP /random-dir-7/random-file.7919
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
such file or directory
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
5367271293300729610, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
such file or directory
16:52:23 (encfs.cpp:138) getattr error: No such file or directory
unique: 0, error: -2 (No such file or directory), outsize: 16
unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 57
LOOKUP /random-dir-7/random-file.7919
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
such file or directory
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
5367271293300729610, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
such file or directory
16:52:23 (encfs.cpp:138) getattr error: No such file or directory
unique: 1, error: -2 (No such file or directory), outsize: 16
unique: 0, opcode: MKNOD (8), nodeid: 60008, insize: 65
MKNOD /random-dir-7/random-file.7919
16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:52:23 (FileNode.cpp:140) calling setIV on (null)
16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
such file or directory
16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
5367271293300729610, fileIV = 0
16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-, mode 33188, dev 0
16:53:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
randBytes = 0
16:53:23 (FileNode.cpp:140) calling setIV on (null)
16:53:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
5367271293300729610, fileIV = 0
16:53:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
16:53:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
NODEID: 67927
unique: 0, error: 0 (Unknown error: 0), outsize: 152
fuse: writing device: Socket is not connected
16:53:27 (openssl.cpp:48) Allocating 35 locks for OpenSSL
Next things I'll try:
Since I think there's some sort of timeout here, I'll try and put
sleeps between the touch commands.
Also, there seems to be some timeout option in Macfuse, so I'll try
that as well.
Then again, it seems weird to me, since this script doesn't give any
problems on any of my 32 bit machines (both Leopard and Snow Leopard
tested), but stops after a minute or 2 on the 64bit SL machine.
Any other suggestions here?
Is there a later/more stable version than the 2.1.9 (Tuxera) version
we currently use? Patches? Known bugs?
thanks!
- Kenny
On Jun 24, 10:38 am, Kenny <psyki...@gmail.com> wrote:
> The Preference pane tells me that the version installed in 2.1.9 ()
> To my knowledge this is still the latest (semi-stable) version that
> supports 64-bit?
> Is there another version I should try out?
> When MacFuse is unmounted (crashed), the encfs process is gone too.
> In case it helps, this is the output from dmesg:
- Added sleep() between 'touch' commands. Does not help, only makes it
work longer.
- Tried updating EncFS to the latest version: didn't help
- Compiled EncFS on Fuse4x (wasn't sure whether it's a problem in
EncFS or MacFuse) and tried that: didn't help. However, since Fuse4x
is just a fork of MacFuse, it could be in both I guess.
- grepped in the sourcecode of both MacFuse (trunk) and EncFS for the
error message: no results found!
I'm stuck here guys, what do I do next?
Where do I look for more logging?
Where does the error come from?
Is anyone else here using 64 bit macs? EncFS?
thanks,
- Kenny
On Jun 27, 5:32 pm, Kenny <psyki...@gmail.com> wrote:
> Hello, I'm still struggling with this, but found a bit more logging
> (still not much I'm afraid) using the -v (verbose) and -d (debug)
> options of both MacFuse and EncFS.
> Any suggestions where I might find more? Or do any of you see any
> fatal errors in this logging?
> So, my test script basically just continuously creates files (touch
> command), on a MacFuse drive with the EncFS filesystem.
> The test script output:
> ...
> Creating file no 7917
> Creating file no 7918
> Creating file no 7919
> touch: /tmp/mount/random-dir-7/random-file.7919: Socket is not
> connected
> Before the error pops up, there is a long time where nothing happens
> and everything seems to hang (timeout?)
> Output from MacFuse/Encfs: (encfs lines start with timestamp, MacFuse
> output does not):
> (note that the file with name 7918 worked properly, it fails when
> attempting to create the file with name 7919)
> The ''No such file or directory" seem normal to me, as they also
> appear in all other (correctly created) files.
> MKNOD /random-dir-7/random-file.7918
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1: No
> such file or directory
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 13721226668822013149, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, mode 33188, dev 0
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 13721226668822013149, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> NODEID: 67926
> unique: 0, error: 0 (Unknown error: 0), outsize: 152
> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 59
> LOOKUP /random-dir-7/._random-file.7918
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
> such file or directory
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 13170079601340108218, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
> such file or directory
> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory
> unique: 1, error: -2 (No such file or directory), outsize: 16
> unique: 0, opcode: GETATTR (3), nodeid: 67926, insize: 40
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 13721226668822013149, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> unique: 0, error: 0 (Unknown error: 0), outsize: 128
> unique: 1, opcode: OPEN (14), nodeid: 67926, insize: 48
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 13721226668822013149, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> 16:52:23 (RawFileIO.cpp:129) open call for writable file
> 16:52:23 (RawFileIO.cpp:151) open file with flags 2, result = 4
> 16:52:23 (encfs.cpp:573) encfs_open for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, flags
> 1
> unique: 1, error: 0 (Unknown error: 0), outsize: 32
> OPEN[40346368] flags: 0x1 /random-dir-7/random-file.7918
> unique: 0, opcode: FLUSH (25), nodeid: 67926, insize: 64
> FLUSH[40346368]
> 16:52:23 (encfs.cpp:134) flush /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> 16:52:23 (RawFileIO.cpp:129) open call for read only file
> 16:52:23 (RawFileIO.cpp:136) using existing file descriptor
> unique: 0, error: 0 (Unknown error: 0), outsize: 16
> unique: 1, opcode: RELEASE (18), nodeid: 67926, insize: 64
> RELEASE[40346368] flags: 0x1
> unique: 1, error: 0 (Unknown error: 0), outsize: 16
> unique: 0, opcode: LOOKUP (1), nodeid: 60008, insize: 57
> LOOKUP /random-dir-7/random-file.7919
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> such file or directory
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 5367271293300729610, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> such file or directory
> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory
> unique: 0, error: -2 (No such file or directory), outsize: 16
> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 57
> LOOKUP /random-dir-7/random-file.7919
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> such file or directory
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 5367271293300729610, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> such file or directory
> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory
> unique: 1, error: -2 (No such file or directory), outsize: 16
> unique: 0, opcode: MKNOD (8), nodeid: 60008, insize: 65
> MKNOD /random-dir-7/random-file.7919
> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> such file or directory
> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 5367271293300729610, fileIV = 0
> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-, mode 33188, dev 0
> 16:53:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> randBytes = 0
> 16:53:23 (FileNode.cpp:140) calling setIV on (null)
> 16:53:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> 5367271293300729610, fileIV = 0
> 16:53:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> 16:53:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> NODEID: 67927
> unique: 0, error: 0 (Unknown error: 0), outsize: 152
> fuse: writing device: Socket is not connected
> 16:53:27 (openssl.cpp:48) Allocating 35 locks for OpenSSL
> Next things I'll try:
> Since I think there's some sort of timeout here, I'll try and put
> sleeps between the touch commands.
> Also, there seems to be some timeout option in Macfuse, so I'll try
On Thu, Jul 7, 2011 at 11:47 PM, Kenny <psyki...@gmail.com> wrote: > So, I tried all of these things:
> - Added sleep() between 'touch' commands. Does not help, only makes it > work longer. > - Tried updating EncFS to the latest version: didn't help > - Compiled EncFS on Fuse4x (wasn't sure whether it's a problem in > EncFS or MacFuse) and tried that: didn't help. However, since Fuse4x > is just a fork of MacFuse, it could be in both I guess. > - grepped in the sourcecode of both MacFuse (trunk) and EncFS for the > error message: no results found!
> I'm stuck here guys, what do I do next? > Where do I look for more logging? > Where does the error come from?
> Is anyone else here using 64 bit macs? EncFS?
> thanks,
> - Kenny
> On Jun 27, 5:32 pm, Kenny <psyki...@gmail.com> wrote: >> Hello, I'm still struggling with this, but found a bit more logging >> (still not much I'm afraid) using the -v (verbose) and -d (debug) >> options of both MacFuse and EncFS. >> Any suggestions where I might find more? Or do any of you see any >> fatal errors in this logging?
>> So, my test script basically just continuously creates files (touch >> command), on a MacFuse drive with the EncFS filesystem.
>> The test script output: >> ... >> Creating file no 7917 >> Creating file no 7918 >> Creating file no 7919 >> touch: /tmp/mount/random-dir-7/random-file.7919: Socket is not >> connected
>> Before the error pops up, there is a long time where nothing happens >> and everything seems to hang (timeout?)
>> Output from MacFuse/Encfs: (encfs lines start with timestamp, MacFuse >> output does not): >> (note that the file with name 7918 worked properly, it fails when >> attempting to create the file with name 7919) >> The ''No such file or directory" seem normal to me, as they also >> appear in all other (correctly created) files.
>> MKNOD /random-dir-7/random-file.7918 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1: No >> such file or directory >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 13721226668822013149, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, mode 33188, dev 0 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 13721226668822013149, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> NODEID: 67926 >> unique: 0, error: 0 (Unknown error: 0), outsize: 152 >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 59 >> LOOKUP /random-dir-7/._random-file.7918 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No >> such file or directory >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 13170079601340108218, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1 >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1 >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No >> such file or directory >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory >> unique: 1, error: -2 (No such file or directory), outsize: 16 >> unique: 0, opcode: GETATTR (3), nodeid: 67926, insize: 40 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 13721226668822013149, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> unique: 0, error: 0 (Unknown error: 0), outsize: 128 >> unique: 1, opcode: OPEN (14), nodeid: 67926, insize: 48 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 13721226668822013149, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> 16:52:23 (RawFileIO.cpp:129) open call for writable file >> 16:52:23 (RawFileIO.cpp:151) open file with flags 2, result = 4 >> 16:52:23 (encfs.cpp:573) encfs_open for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, flags >> 1 >> unique: 1, error: 0 (Unknown error: 0), outsize: 32 >> OPEN[40346368] flags: 0x1 /random-dir-7/random-file.7918 >> unique: 0, opcode: FLUSH (25), nodeid: 67926, insize: 64 >> FLUSH[40346368] >> 16:52:23 (encfs.cpp:134) flush /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 >> 16:52:23 (RawFileIO.cpp:129) open call for read only file >> 16:52:23 (RawFileIO.cpp:136) using existing file descriptor >> unique: 0, error: 0 (Unknown error: 0), outsize: 16 >> unique: 1, opcode: RELEASE (18), nodeid: 67926, insize: 64 >> RELEASE[40346368] flags: 0x1 >> unique: 1, error: 0 (Unknown error: 0), outsize: 16 >> unique: 0, opcode: LOOKUP (1), nodeid: 60008, insize: 57 >> LOOKUP /random-dir-7/random-file.7919 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No >> such file or directory >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 5367271293300729610, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No >> such file or directory >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory >> unique: 0, error: -2 (No such file or directory), outsize: 16 >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 57 >> LOOKUP /random-dir-7/random-file.7919 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No >> such file or directory >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 5367271293300729610, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No >> such file or directory >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory >> unique: 1, error: -2 (No such file or directory), outsize: 16 >> unique: 0, opcode: MKNOD (8), nodeid: 60008, insize: 65 >> MKNOD /random-dir-7/random-file.7919 >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No >> such file or directory >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 5367271293300729610, fileIV = 0 >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-, mode 33188, dev 0 >> 16:53:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, >> randBytes = 0 >> 16:53:23 (FileNode.cpp:140) calling setIV on (null) >> 16:53:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = >> 5367271293300729610, fileIV = 0 >> 16:53:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> 16:53:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- >> NODEID: 67927 >> unique: 0, error: 0 (Unknown error: 0), outsize: 152 >> fuse: writing device: Socket is not connected
On Thu, Jul 7, 2011 at 7:44 AM, Sam Moffatt <pasa...@gmail.com> wrote: > Have you tried attaching a debugger to the process and seeing if it's > hitting some weird error case somewhere and terminating/being > terminated?
ENOTCONN ("Socket is not connected") is a standard kext error in case if the fuse daemon does not respond. It makes me think that encfs daemon is dead at the moment you try to do "ls DIR". Are you sure that /var/log/system.log does not have any logs related to fuse?
A few pointers that might shed some light: - run encfs with verbose and fuse debug enabled. Add "-v -d" to encfs flags. - make sure that encfs daemon is running "ps ax | grep -i encfs" - make sure that the folder is mounted "mount | grep -i fuse" - run "sysctl macfuse.resourceusage.mounts"
On Thu, Jul 7, 2011 at 11:47 PM, Kenny <psyki...@gmail.com> wrote: > > So, I tried all of these things:
> > - Added sleep() between 'touch' commands. Does not help, only makes it > > work longer. > > - Tried updating EncFS to the latest version: didn't help > > - Compiled EncFS on Fuse4x (wasn't sure whether it's a problem in > > EncFS or MacFuse) and tried that: didn't help. However, since Fuse4x > > is just a fork of MacFuse, it could be in both I guess. > > - grepped in the sourcecode of both MacFuse (trunk) and EncFS for the > > error message: no results found!
> > I'm stuck here guys, what do I do next? > > Where do I look for more logging? > > Where does the error come from?
> > Is anyone else here using 64 bit macs? EncFS?
> > thanks,
> > - Kenny
> > On Jun 27, 5:32 pm, Kenny <psyki...@gmail.com> wrote: > >> Hello, I'm still struggling with this, but found a bit more logging > >> (still not much I'm afraid) using the -v (verbose) and -d (debug) > >> options of both MacFuse and EncFS. > >> Any suggestions where I might find more? Or do any of you see any > >> fatal errors in this logging?
> >> So, my test script basically just continuously creates files (touch > >> command), on a MacFuse drive with the EncFS filesystem.
> >> The test script output: > >> ... > >> Creating file no 7917 > >> Creating file no 7918 > >> Creating file no 7919 > >> touch: /tmp/mount/random-dir-7/random-file.7919: Socket is not > >> connected
> >> Before the error pops up, there is a long time where nothing happens > >> and everything seems to hang (timeout?)
> >> Output from MacFuse/Encfs: (encfs lines start with timestamp, MacFuse > >> output does not): > >> (note that the file with name 7918 worked properly, it fails when > >> attempting to create the file with name 7919) > >> The ''No such file or directory" seem normal to me, as they also > >> appear in all other (correctly created) files.
> >> MKNOD /random-dir-7/random-file.7918 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1: No > >> such file or directory > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 13721226668822013149, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, mode 33188, dev 0 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 13721226668822013149, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> NODEID: 67926 > >> unique: 0, error: 0 (Unknown error: 0), outsize: 152 > >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 59 > >> LOOKUP /random-dir-7/._random-file.7918 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No > >> such file or directory > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 13170079601340108218, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1 > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1 > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No > >> such file or directory > >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory > >> unique: 1, error: -2 (No such file or directory), outsize: 16 > >> unique: 0, opcode: GETATTR (3), nodeid: 67926, insize: 40 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 13721226668822013149, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> unique: 0, error: 0 (Unknown error: 0), outsize: 128 > >> unique: 1, opcode: OPEN (14), nodeid: 67926, insize: 48 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 13721226668822013149, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> 16:52:23 (RawFileIO.cpp:129) open call for writable file > >> 16:52:23 (RawFileIO.cpp:151) open file with flags 2, result = 4 > >> 16:52:23 (encfs.cpp:573) encfs_open for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, flags > >> 1 > >> unique: 1, error: 0 (Unknown error: 0), outsize: 32 > >> OPEN[40346368] flags: 0x1 /random-dir-7/random-file.7918 > >> unique: 0, opcode: FLUSH (25), nodeid: 67926, insize: 64 > >> FLUSH[40346368] > >> 16:52:23 (encfs.cpp:134) flush /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1 > >> 16:52:23 (RawFileIO.cpp:129) open call for read only file > >> 16:52:23 (RawFileIO.cpp:136) using existing file descriptor > >> unique: 0, error: 0 (Unknown error: 0), outsize: 16 > >> unique: 1, opcode: RELEASE (18), nodeid: 67926, insize: 64 > >> RELEASE[40346368] flags: 0x1 > >> unique: 1, error: 0 (Unknown error: 0), outsize: 16 > >> unique: 0, opcode: LOOKUP (1), nodeid: 60008, insize: 57 > >> LOOKUP /random-dir-7/random-file.7919 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No > >> such file or directory > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 5367271293300729610, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No > >> such file or directory > >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory > >> unique: 0, error: -2 (No such file or directory), outsize: 16 > >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 57 > >> LOOKUP /random-dir-7/random-file.7919 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No > >> such file or directory > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV = > >> 5367271293300729610, fileIV = 0 > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/ > >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh- > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No > >> such file or directory > >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory > >> unique: 1, error: -2 (No such file or directory), outsize: 16 > >> unique: 0, opcode: MKNOD (8), nodeid: 60008, insize: 65 > >> MKNOD /random-dir-7/random-file.7919 > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8, > >> randBytes = 0 > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null) > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS- > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No > >> such file or directory > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
Thanks for the pointers.
- enable verbose debug logging. see output in original post, no errors
other than 'fuse: writing device: socket is not connected'
- ps ax | grep -i encfs: this is the problem, when the error occurs,
everything is unmounted, the process ends, so no results here: encfs
is gone
- mount | grep -i fuse: Same as above. Everything is automatically
unmounted after this. No mount entries remain
- sysctl: returns 1 while mounted, 0 after it 'crashed'.
Other than the error message 'socket not connected', it's as if the
volume was ejected properly.
Seems cleanly unmounted, no dirty errors, no mount entries remaining,
nothing..
On Jul 7, 9:18 pm, Anatol Pomozov <anatol.pomo...@gmail.com> wrote:
> On Thu, Jul 7, 2011 at 7:44 AM, Sam Moffatt <pasa...@gmail.com> wrote:
> > Have you tried attaching a debugger to the process and seeing if it's
> > hitting some weird error case somewhere and terminating/being
> > terminated?
> ENOTCONN ("Socket is not connected") is a standard kext error in case if the
> fuse daemon does not respond. It makes me think that encfs daemon is dead at
> the moment you try to do "ls DIR". Are you sure that /var/log/system.log
> does not have any logs related to fuse?
> A few pointers that might shed some light:
> - run encfs with verbose and fuse debug enabled. Add "-v -d" to encfs
> flags.
> - make sure that encfs daemon is running "ps ax | grep -i encfs"
> - make sure that the folder is mounted "mount | grep -i fuse"
> - run "sysctl macfuse.resourceusage.mounts"
> On Thu, Jul 7, 2011 at 11:47 PM, Kenny <psyki...@gmail.com> wrote:
> > > So, I tried all of these things:
> > > - Added sleep() between 'touch' commands. Does not help, only makes it
> > > work longer.
> > > - Tried updating EncFS to the latest version: didn't help
> > > - Compiled EncFS on Fuse4x (wasn't sure whether it's a problem in
> > > EncFS or MacFuse) and tried that: didn't help. However, since Fuse4x
> > > is just a fork of MacFuse, it could be in both I guess.
> > > - grepped in the sourcecode of both MacFuse (trunk) and EncFS for the
> > > error message: no results found!
> > > I'm stuck here guys, what do I do next?
> > > Where do I look for more logging?
> > > Where does the error come from?
> > > Is anyone else here using 64 bit macs? EncFS?
> > > thanks,
> > > - Kenny
> > > On Jun 27, 5:32 pm, Kenny <psyki...@gmail.com> wrote:
> > >> Hello, I'm still struggling with this, but found a bit more logging
> > >> (still not much I'm afraid) using the -v (verbose) and -d (debug)
> > >> options of both MacFuse and EncFS.
> > >> Any suggestions where I might find more? Or do any of you see any
> > >> fatal errors in this logging?
> > >> So, my test script basically just continuously creates files (touch
> > >> command), on a MacFuse drive with the EncFS filesystem.
> > >> The test script output:
> > >> ...
> > >> Creating file no 7917
> > >> Creating file no 7918
> > >> Creating file no 7919
> > >> touch: /tmp/mount/random-dir-7/random-file.7919: Socket is not
> > >> connected
> > >> Before the error pops up, there is a long time where nothing happens
> > >> and everything seems to hang (timeout?)
> > >> Output from MacFuse/Encfs: (encfs lines start with timestamp, MacFuse
> > >> output does not):
> > >> (note that the file with name 7918 worked properly, it fails when
> > >> attempting to create the file with name 7919)
> > >> The ''No such file or directory" seem normal to me, as they also
> > >> appear in all other (correctly created) files.
> > >> MKNOD /random-dir-7/random-file.7918
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1: No
> > >> such file or directory
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 13721226668822013149, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> 16:52:23 (encfs.cpp:258) mknod on /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, mode 33188, dev 0
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 13721226668822013149, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> NODEID: 67926
> > >> unique: 0, error: 0 (Unknown error: 0), outsize: 152
> > >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 59
> > >> LOOKUP /random-dir-7/._random-file.7918
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
> > >> such file or directory
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 13170079601340108218, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
> > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/nxdd5Xs1tCWupzTPBEDilZU26j,vVI3SmgM72IaRCgmGZ1: No
> > >> such file or directory
> > >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory
> > >> unique: 1, error: -2 (No such file or directory), outsize: 16
> > >> unique: 0, opcode: GETATTR (3), nodeid: 67926, insize: 40
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 13721226668822013149, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> unique: 0, error: 0 (Unknown error: 0), outsize: 128
> > >> unique: 1, opcode: OPEN (14), nodeid: 67926, insize: 48
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 13721226668822013149, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> 16:52:23 (RawFileIO.cpp:129) open call for writable file
> > >> 16:52:23 (RawFileIO.cpp:151) open file with flags 2, result = 4
> > >> 16:52:23 (encfs.cpp:573) encfs_open for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1, flags
> > >> 1
> > >> unique: 1, error: 0 (Unknown error: 0), outsize: 32
> > >> OPEN[40346368] flags: 0x1 /random-dir-7/random-file.7918
> > >> unique: 0, opcode: FLUSH (25), nodeid: 67926, insize: 64
> > >> FLUSH[40346368]
> > >> 16:52:23 (encfs.cpp:134) flush /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> 7CcwjpnquD-XgwYpu5bSoOxRjP3JOMIrE8gEOReUoXU4H1
> > >> 16:52:23 (RawFileIO.cpp:129) open call for read only file
> > >> 16:52:23 (RawFileIO.cpp:136) using existing file descriptor
> > >> unique: 0, error: 0 (Unknown error: 0), outsize: 16
> > >> unique: 1, opcode: RELEASE (18), nodeid: 67926, insize: 64
> > >> RELEASE[40346368] flags: 0x1
> > >> unique: 1, error: 0 (Unknown error: 0), outsize: 16
> > >> unique: 0, opcode: LOOKUP (1), nodeid: 60008, insize: 57
> > >> LOOKUP /random-dir-7/random-file.7919
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> > >> such file or directory
> > >> 16:52:23 (CipherFileIO.cpp:105) in setIV, current IV = 0, new IV =
> > >> 5367271293300729610, fileIV = 0
> > >> 16:52:23 (DirNode.cpp:781) created FileNode for /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> > >> 16:52:23 (encfs.cpp:134) getattr /tmp/data/ocZ1JyZS-ZXhUW,Chp7bssyC/
> > >> jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> > >> ZXhUW,Chp7bssyC/jmCF1r7QMlbm7xvYpXfY1DnaOhJhp6IZR9DAo2ElO53nh-: No
> > >> such file or directory
> > >> 16:52:23 (encfs.cpp:138) getattr error: No such file or directory
> > >> unique: 0, error: -2 (No such file or directory), outsize: 16
> > >> unique: 1, opcode: LOOKUP (1), nodeid: 60008, insize: 57
> > >> LOOKUP /random-dir-7/random-file.7919
> > >> 16:52:23 (MACFileIO.cpp:67) fs block size = 1024, macBytes = 8,
> > >> randBytes = 0
> > >> 16:52:23 (FileNode.cpp:140) calling setIV on (null)
> > >> 16:52:23 (RawFileIO.cpp:191) getAttr error on /tmp/data/ocZ1JyZS-
> We've been using MacFuse for a long time with EncFS, on multiple
> machines.
> It's never given me any problems. (on 32 bit machines with both
> Leopard and Snow Leopard).
> However, we've recently added a few new machines. They come standard
> with Snow Leopard and 64 bit enabled now.
> On the 64bit machines, it seems the images are regularly unmounted
> without notice.
> I wrote a small script that can reproduce quite fast.
> It doesn't do much, it just continuously creates new directories and
> touches (creates) files in them.
> This works fine for a long time, but after a while, the 'touch' seems
> to take very long, and eventually 'times out' with the error:
> Socket is not connected.
> At this point, the drive is no longer mounted.
> (mount doesn't display it anymore, mountpoint directory inode is no
> longer the same as the data directory inode)
> It just disappeared....
> I looked at the logs in Console.app, and in /var/log/syslog, but
> nothing is added in there.
> In dmesg, I do see fuse references, but nothing that points to a bug/
> crash.
> Is this a known problem? Is there a fix/workaround?
> Where should I look for more logging?
> Is this a MacFuse error, or is this specific to EncFS and should I
> report a bug there?
> Do you guys use 64bit macs? Have you encountered the same problems?
I get many thank you comments from people, so I can only hope it helps
them. I can't take any credit for the work however, since I just
compiled Tuxera's 'rebel' source code.
I am trying to figure out how to compile for Lion, and I've made some
progress, but so far I am stuck on a check in the build script, I'll
have to start understanding how it works I guess.
On Jul 18, 6:24 am, jb <boylejo...@googlemail.com> wrote:
> On Jun 23, 2:32 pm, Kenny <psyki...@gmail.com> wrote:
> > Hi,
> > We've been using MacFuse for a long time with EncFS, on multiple
> > machines.
> > It's never given me any problems. (on 32 bit machines with both
> > Leopard and Snow Leopard).
> > However, we've recently added a few new machines. They come standard
> > with Snow Leopard and 64 bit enabled now.
> > On the 64bit machines, it seems the images are regularly unmounted
> > without notice.
> > I wrote a small script that can reproduce quite fast.
> > It doesn't do much, it just continuously creates new directories and
> > touches (creates) files in them.
> > This works fine for a long time, but after a while, the 'touch' seems
> > to take very long, and eventually 'times out' with the error:
> > Socket is not connected.
> > At this point, the drive is no longer mounted.
> > (mount doesn't display it anymore, mountpoint directory inode is no
> > longer the same as the data directory inode)
> > It just disappeared....
> > I looked at the logs in Console.app, and in /var/log/syslog, but
> > nothing is added in there.
> > In dmesg, I do see fuse references, but nothing that points to a bug/
> > crash.
> > Is this a known problem? Is there a fix/workaround?
> > Where should I look for more logging?
> > Is this a MacFuse error, or is this specific to EncFS and should I
> > report a bug there?
> > Do you guys use 64bit macs? Have you encountered the same problems?
check out OSXFUSE. There has been some quite some messages in the past about OSXFUSE on this mailinglist. OSXFUSE is compatible with Leopard through Lion and features a compatibility layer to be compatible with "all" existing MacFUSE filesystems ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik (the author of the rebel branch) and I are the the owners of the OSXFUSE project.
You can find some instructions on building OSXFUSE in the group. If you need assistance, feel free to ask. But please hold off from distributing any builds. The update mechanism has not been set up and there are a few other things I'm working on right now. Non the less OSXFUSE's core feature is already fully functional.
I will post an official beta in in the next two or three days. More information to come. Just thought I'd let you know. We don't need another MacFUSE fork/build around. The situation is already a mess as it is. But I will highly appreciate you spreading the word when we are ready, in a few days. You blog post has helped quite some people.
> I get many thank you comments from people, so I can only hope it helps > them. I can't take any credit for the work however, since I just > compiled Tuxera's 'rebel' source code.
> I am trying to figure out how to compile for Lion, and I've made some > progress, but so far I am stuck on a check in the build script, I'll > have to start understanding how it works I guess.
Oh, this is great, I will check it out. I've spent quite a bit of time
today getting the Tuxera MacFuse to compile on Lion, but since I don't
know anything about the kernel extensions or MacFuse, I have no
confidence it works.
For example, It appears the current code uses the "ucred" struct in
userspace, but apparently in SDK 10.7 this has become an internal API
and is no longer available, so I needed to compile some userspace code
with SDK 10.6....
I also needed to drop -Werror because of newly deprecated call...
I'll take a look at osxfuse, Thanks!
On Jul 21, 4:30 am, Benjamin Fleischer <flei...@gmail.com> wrote:
> check out OSXFUSE. There has been some quite some messages in the past about OSXFUSE on this mailinglist.
> OSXFUSE is compatible with Leopard through Lion and features a compatibility layer to be compatible with "all" existing MacFUSE filesystems ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
> OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik (the author of the rebel branch) and I are the the owners of the OSXFUSE project.
> You can find some instructions on building OSXFUSE in the group. If you need assistance, feel free to ask. But please hold off from distributing any builds. The update mechanism has not been set up and there are a few other things I'm working on right now. Non the less OSXFUSE's core feature is already fully functional.
> I will post an official beta in in the next two or three days. More information to come. Just thought I'd let you know. We don't need another MacFUSE fork/build around. The situation is already a mess as it is. But I will highly appreciate you spreading the word when we are ready, in a few days. You blog post has helped quite some people.
> Regards,
> Benjamin
> Am 21.07.2011 um 07:02 schrieb Josh:
> > Hello, I am the author of the blog post jb links to below. The direct
> > link to the page is here:
> > I get many thank you comments from people, so I can only hope it helps
> > them. I can't take any credit for the work however, since I just
> > compiled Tuxera's 'rebel' source code.
> > I am trying to figure out how to compile for Lion, and I've made some
> > progress, but so far I am stuck on a check in the build script, I'll
> > have to start understanding how it works I guess.
On Jul 21, 4:30 am, Benjamin Fleischer <flei...@gmail.com> wrote:
> I will post an official beta in in the next two or three days. More information to come. Just thought I'd let you know. We don't need another MacFUSE fork/build around. The situation is already a mess as it is. But I will highly appreciate you spreading the word when we are ready, in a few days. You blog post has helped quite some people.
Sorry about the double reply, I hadn't read your whole email... I
agree 100%, I will post an update on my blog post and recommend people
looking for Lion support check out your project.
FYI: The upcoming version of Fuse4X will include additional *.dylib files that are binary compatible with MacFUSE [1] so any application will work with Fuse4X without recompiling. Fuse4X is going to include compatible MacFUSE.framework as well [2].
FYI 2: there is an ongoing conversation with Miklos about merging MacFUSE/Fuse4X changes to the upstream project (don't forget that MacFUSE is a fork itself). It'll take some time though, at least a few months.
[1] Well, it won't be 100% compatible. Fuse4X has a few changes in fuse behavior (e.g. async mount(); fuse4x does not block SIGCHLD anymore; does not changes semaphores implementation from Darwin; has some de-initialization changes...). But assuming that the most filesystems are written for Linux (encfs, truecrypt, sshfs,...) with the upstream fuse behavior in mind it these changes will not break them. Even more - as Fuse4X follows standard closer these applications will work more stable and have less problems.
[2] It is still not clear to me the legal question around MacFUSE name. This brand belongs to Google and Amit explicitly asked not to use it so I am not sure if I can distribute/change MacFUSE.framework. So I need to clarify it with Google first or just wait until Google contacts and asks to remove MacFUSE.framework from the distribution package.
On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <flei...@gmail.com>wrote:
> check out OSXFUSE. There has been some quite some messages in the past > about OSXFUSE on this mailinglist. > OSXFUSE is compatible with Leopard through Lion and features a > compatibility layer to be compatible with "all" existing MacFUSE filesystems > ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary > compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be > recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
> OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik (the > author of the rebel branch) and I are the the owners of the OSXFUSE project.
> You can find some instructions on building OSXFUSE in the group. If you > need assistance, feel free to ask. But please hold off from distributing any > builds. The update mechanism has not been set up and there are a few other > things I'm working on right now. Non the less OSXFUSE's core feature is > already fully functional.
> I will post an official beta in in the next two or three days. More > information to come. Just thought I'd let you know. We don't need another > MacFUSE fork/build around. The situation is already a mess as it is. But I > will highly appreciate you spreading the word when we are ready, in a few > days. You blog post has helped quite some people.
> Regards, > Benjamin
> Am 21.07.2011 um 07:02 schrieb Josh:
> Hello, I am the author of the blog post jb links to below. The direct > link to the page is here:
> I get many thank you comments from people, so I can only hope it helps > them. I can't take any credit for the work however, since I just > compiled Tuxera's 'rebel' source code.
> I am trying to figure out how to compile for Lion, and I've made some > progress, but so far I am stuck on a check in the build script, I'll > have to start understanding how it works I guess.
> -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
> FYI: The upcoming version of Fuse4X will include additional *.dylib > files that are binary compatible with MacFUSE [1] so any application > will work with Fuse4X without recompiling. Fuse4X is going to include > compatible MacFUSE.framework as well [2].
Ok, so what is the difference between OSXFUSE and FUSE4X now again? :)
> FYI 2: there is an ongoing conversation with Miklos about merging > MacFUSE/Fuse4X changes to the upstream project (don't forget that > MacFUSE is a fork itself). It'll take some time though, at least a few > months.
This would be the libfuse changes I assume. This would be much welcome, but please make sure that generic MacFUSE changes are merged and not changes that diverge between MacFUSE / FUSE4X / OSXFUSE (at least we need to agree between FUSE4X and OSXFUSE on pushing such changes upstream as it affects us both).
> [1] Well, it won't be 100% compatible. Fuse4X has a few changes in > fuse behavior (e.g. async mount(); fuse4x does not block SIGCHLD > anymore; does not changes semaphores implementation from Darwin; has > some de-initialization changes...). But assuming that the most > filesystems are written for Linux (encfs, truecrypt, sshfs,...) with > the upstream fuse behavior in mind it these changes will not break > them. Even more - as Fuse4X follows standard closer these applications > will work more stable and have less problems.
> [2] It is still not clear to me the legal question around MacFUSE > name. This brand belongs to Google and Amit explicitly asked not to > use it so I am not sure if I can distribute/change MacFUSE.framework. > So I need to clarify it with Google first or just wait until Google > contacts and asks to remove MacFUSE.framework from > the distribution package.
MacFUSE isn't really a registered trademark of either Amit or Google, is it? (I sincerely doubt that they would find MacFUSE to be worth protecting as a trademark.) It's not realistic to change all occurrences of 'MacFUSE' into something else, as this would mean that we have no chance of being compatible with existing software... especially in the case of MacFUSE.framework.
How far is the 'rebranding' expected to go? With this strict interpretation of brand ownership and usage we are all handcuffed when it comes to being compatible with existing binaries. (Amit is as always welcome to speak his mind... if he hasn't terminated his membership in this group.)
> On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <flei...@gmail.com > <mailto:flei...@gmail.com>> wrote:
> Hi Josh,
> check out OSXFUSE. There has been some quite some messages in the > past about OSXFUSE on this mailinglist. > OSXFUSE is compatible with Leopard through Lion and features a > compatibility layer to be compatible with "all" existing MacFUSE > filesystems ("all" in: I could not test all, but OSXFUSE and > MacFUSE are binary compatible). Unlike Fuse4X the MacFUSE > filesystems don't even have to be recompiled! OSXFUSE is a drop-in > replacement for MacFUSE.
> OSXFUSE has been build on Tuxera's rebel branch and my sources. > Erik (the author of the rebel branch) and I are the the owners of > the OSXFUSE project.
> You can find some instructions on building OSXFUSE in the group. > If you need assistance, feel free to ask. But please hold off from > distributing any builds. The update mechanism has not been set up > and there are a few other things I'm working on right now. Non the > less OSXFUSE's core feature is already fully functional.
> I will post an official beta in in the next two or three days. > More information to come. Just thought I'd let you know. We don't > need another MacFUSE fork/build around. The situation is already a > mess as it is. But I will highly appreciate you spreading the word > when we are ready, in a few days. You blog post has helped quite > some people.
> Regards, > Benjamin
> Am 21.07.2011 um 07:02 schrieb Josh:
>> Hello, I am the author of the blog post jb links to below. The direct >> link to the page is here:
>> I get many thank you comments from people, so I can only hope it >> helps >> them. I can't take any credit for the work however, since I just >> compiled Tuxera's 'rebel' source code.
>> I am trying to figure out how to compile for Lion, and I've made some >> progress, but so far I am stuck on a check in the build script, I'll >> have to start understanding how it works I guess.
> -- > You received this message because you are subscribed to the Google > Groups "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com > <mailto:macfuse@googlegroups.com>. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com > <mailto:macfuse%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
> -- > You received this message because you are subscribed to the Google > Groups "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
On Thu, Jul 21, 2011 at 4:01 PM, Josh <pardsb...@gmail.com> wrote: > For example, It appears the current code uses the "ucred" struct in > userspace, but apparently in SDK 10.7 this has become an internal API > and is no longer available, so I needed to compile some userspace code > with SDK 10.6....
> I also needed to drop -Werror because of newly deprecated call...
> I'll take a look at osxfuse, Thanks!
> On Jul 21, 4:30 am, Benjamin Fleischer <flei...@gmail.com> wrote: > > Hi Josh,
> > check out OSXFUSE. There has been some quite some messages in the past > about OSXFUSE on this mailinglist. > > OSXFUSE is compatible with Leopard through Lion and features a > compatibility layer to be compatible with "all" existing MacFUSE filesystems > ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary > compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be > recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
> > OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik (the > author of the rebel branch) and I are the the owners of the OSXFUSE project.
> > You can find some instructions on building OSXFUSE in the group. If you > need assistance, feel free to ask. But please hold off from distributing any > builds. The update mechanism has not been set up and there are a few other > things I'm working on right now. Non the less OSXFUSE's core feature is > already fully functional.
> > I will post an official beta in in the next two or three days. More > information to come. Just thought I'd let you know. We don't need another > MacFUSE fork/build around. The situation is already a mess as it is. But I > will highly appreciate you spreading the word when we are ready, in a few > days. You blog post has helped quite some people.
> > Regards, > > Benjamin
> > Am 21.07.2011 um 07:02 schrieb Josh:
> > > Hello, I am the author of the blog post jb links to below. The direct > > > link to the page is here:
> > > I get many thank you comments from people, so I can only hope it helps > > > them. I can't take any credit for the work however, since I just > > > compiled Tuxera's 'rebel' source code.
> > > I am trying to figure out how to compile for Lion, and I've made some > > > progress, but so far I am stuck on a check in the build script, I'll > > > have to start understanding how it works I guess.
> -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
On Thu, Jul 21, 2011 at 9:34 PM, Erik Larsson <catacom...@gmail.com> wrote: > ** > Hi,
> Anatol Pomozov wrote 2011-07-22 02.33:
> FYI: The upcoming version of Fuse4X will include additional *.dylib files > that are binary compatible with MacFUSE [1] so any application will work > with Fuse4X without recompiling. Fuse4X is going to include compatible > MacFUSE.framework as well [2].
> Ok, so what is the difference between OSXFUSE and FUSE4X now again? :)
Fuse4X project exists for 1.5 months already, while OSXFUSE still not alive. The technical differences that I remember from top of my head: - fuse_mount operation made async. Without it fuse_mount() function is blocked until fuse daemon responses with FUSE_INIT. But in this case you cannot use low-level fuse API like this one: fuse_mount(); fuse_new(); fuse_loop(); - macfuse/osxfuse blocks SIGCHLD. This is just a horrible macfuse decision - you cannot use macfuse/osxfuse in multithread applications (wait() function does not work). - removed mount_fusefs binary. In linux and FreeBSD mount() syscall is privileged so one needs a binary with suid bit that user can use for mount(). Darwin does not need it - mount logic can be made much more simple and faster. - uninitialization logic in macfuse is just horrible. fuse4x simplifies it and makes straight. - a bunch of code cleanup in kext/libfuse - public header macfuse_darwin.h in macfuse replaces semaphores with its own implementation based on pthreads (it is actually slightly changed libsem library from GNU Hurd). Fuse4x removes it as it is not a responsibility of the fuse library publicly replace Darwin core functionality. - one more thing that I do not like in macfuse is fuse.pc vs fuse_i64.pc thing - macfuse (and I believe osxfuse) distributes 2 dynamic libraries, one for 32 another for 64 bit inodes. Instead one should use symbol variants. See more info here http://developer.apple.com/library/mac/#releasenotes/Darwin/SymbolVar...
OSXFuse is just rebranded Tuxera macfuse and nothing more. It is fully backward compatible with macfuse though, while fuse4x drops some functions and changed behavior described above.
Benjamin decided to follow "osxfuse is not fuse" way [1], while fuse4x follows "fuse4x *is* fuse". So osxfuse puts itself into trap when it have to keep and support all macfuse bugs in sake of backward compatibility with macfuse. Fuse4x does not try to be fully backward compatible with macfuse, instead it tries to be compatible with the upstream implementation.
The fact is that macfuse/osxfuse is not compatible you can check by trying to run following program https://gist.github.com/1101067 It runs perfectly fine on the upstream Linux while hangs with macfuse/osxfuse.
You might ask "What about existing programs that currently use macfuse? Do they need to be recompiled?" If your filesystem works fine with MacFUSE just continue using it - no need to do any changes. There is an unofficial build from Tuxera that works fine with Lion. But if you care about being compatible with the upstream fuse - use fuse4x. Applications that use fuse4x can coexist with applications that use macfuse.
The next release of fuse4x will add back some of the removed functions and provide additional ABI compatible dylibs. It is needed to people who does not want to use macfuse from Tuxera for some reason.
FYI 2: there is an ongoing conversation with Miklos about merging
> MacFUSE/Fuse4X changes to the upstream project (don't forget that MacFUSE is > a fork itself). It'll take some time though, at least a few months.
> This would be the libfuse changes I assume. This would be much welcome, but > please make sure that generic MacFUSE changes are merged and not changes > that diverge between MacFUSE / FUSE4X / OSXFUSE (at least we need to agree > between FUSE4X and OSXFUSE on pushing such changes upstream as it affects us > both).
> [1] Well, it won't be 100% compatible. Fuse4X has a few changes in fuse > behavior (e.g. async mount(); fuse4x does not block SIGCHLD anymore; does > not changes semaphores implementation from Darwin; has some > de-initialization changes...). But assuming that the most filesystems are > written for Linux (encfs, truecrypt, sshfs,...) with the upstream fuse > behavior in mind it these changes will not break them. Even more - as Fuse4X > follows standard closer these applications will work more stable and have > less problems.
> [2] It is still not clear to me the legal question around MacFUSE name. > This brand belongs to Google and Amit explicitly asked not to use it so I am > not sure if I can distribute/change MacFUSE.framework. So I need to clarify > it with Google first or just wait until Google contacts and asks to > remove MacFUSE.framework from the distribution package.
> MacFUSE isn't really a registered trademark of either Amit or Google, is > it? (I sincerely doubt that they would find MacFUSE to be worth protecting > as a trademark.) > It's not realistic to change all occurrences of 'MacFUSE' into something > else, as this would mean that we have no chance of being compatible with > existing software... especially in the case of MacFUSE.framework.
> How far is the 'rebranding' expected to go? With this strict interpretation > of brand ownership and usage we are all handcuffed when it comes to being > compatible with existing binaries. > (Amit is as always welcome to speak his mind... if he hasn't terminated his > membership in this group.)
> Regards,
> - Erik
> On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <flei...@gmail.com>wrote:
>> Hi Josh,
>> check out OSXFUSE. There has been some quite some messages in the past >> about OSXFUSE on this mailinglist. >> OSXFUSE is compatible with Leopard through Lion and features a >> compatibility layer to be compatible with "all" existing MacFUSE filesystems >> ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary >> compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be >> recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
>> OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik >> (the author of the rebel branch) and I are the the owners of the OSXFUSE >> project.
>> You can find some instructions on building OSXFUSE in the group. If you >> need assistance, feel free to ask. But please hold off from distributing any >> builds. The update mechanism has not been set up and there are a few other >> things I'm working on right now. Non the less OSXFUSE's core feature is >> already fully functional.
>> I will post an official beta in in the next two or three days. More >> information to come. Just thought I'd let you know. We don't need another >> MacFUSE fork/build around. The situation is already a mess as it is. But I >> will highly appreciate you spreading the word when we are ready, in a few >> days. You blog post has helped quite some people.
>> Regards, >> Benjamin
>> Am 21.07.2011 um 07:02 schrieb Josh:
>> Hello, I am the author of the blog post jb links to below. The direct >> link to the page is here:
>> I get many thank you comments from people, so I can only hope it helps >> them. I can't take any credit for the work however, since I just >> compiled Tuxera's 'rebel' source code.
>> I am trying to figure out how to compile for Lion, and I've made some >> progress, but so far I am stuck on a check in the build script, I'll >> have to start understanding how it works I guess.
>> -- >> You received this message because you are subscribed to the Google Groups >> "MacFUSE" group. >> To post to this group, send email to macfuse@googlegroups.com. >> To unsubscribe from this group, send email to >> macfuse+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/macfuse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "MacFUSE" group. > To post to this group, send email to macfuse@googlegroups.com. > To unsubscribe from this group, send email to > macfuse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/macfuse?hl=en.
> On Thu, Jul 21, 2011 at 9:34 PM, Erik Larsson <catacom...@gmail.com>wrote:
>> ** >> Hi,
>> Anatol Pomozov wrote 2011-07-22 02.33:
>> FYI: The upcoming version of Fuse4X will include additional *.dylib files >> that are binary compatible with MacFUSE [1] so any application will work >> with Fuse4X without recompiling. Fuse4X is going to include compatible >> MacFUSE.framework as well [2].
>> Ok, so what is the difference between OSXFUSE and FUSE4X now again? :)
> Fuse4X project exists for 1.5 months already, while OSXFUSE still not > alive. > The technical differences that I remember from top of my head: > - fuse_mount operation made async. Without it fuse_mount() function is > blocked until fuse daemon responses with FUSE_INIT. But in this case you > cannot use low-level fuse API like this one: > fuse_mount(); fuse_new(); fuse_loop();
sorry it was wrong example. Here is the one that describes the problem with sync mount in macfuse/osxfuse
fuse_mount(); fuse_new(); pthread_create(fuse_loop); // run fuse_loop in a separate thread or process access_the_filesystem(); // on linux any access to filesystem at this point is blocked until the fs is available. On macfuse it fails as fs might not be mounted yet (it marked as mounted only after receiving FUSE_INIT).
- macfuse/osxfuse blocks SIGCHLD. This is just a horrible macfuse decision
> - you cannot use macfuse/osxfuse in multithread applications (wait() > function does not work). > - removed mount_fusefs binary. In linux and FreeBSD mount() syscall is > privileged so one needs a binary with suid bit that user can use for > mount(). Darwin does not need it - mount logic can be made much more simple > and faster. > - uninitialization logic in macfuse is just horrible. fuse4x simplifies it > and makes straight. > - a bunch of code cleanup in kext/libfuse > - public header macfuse_darwin.h in macfuse replaces semaphores with its > own implementation based on pthreads (it is actually slightly changed libsem > library from GNU Hurd). Fuse4x removes it as it is not a responsibility of > the fuse library publicly replace Darwin core functionality. > - one more thing that I do not like in macfuse is fuse.pc vs fuse_i64.pc > thing - macfuse (and I believe osxfuse) distributes 2 dynamic libraries, one > for 32 another for 64 bit inodes. Instead one should use symbol variants. > See more info here > http://developer.apple.com/library/mac/#releasenotes/Darwin/SymbolVar...
> OSXFuse is just rebranded Tuxera macfuse and nothing more. It is fully > backward compatible with macfuse though, while fuse4x drops some functions > and changed behavior described above.
> Benjamin decided to follow "osxfuse is not fuse" way [1], while fuse4x > follows "fuse4x *is* fuse". So osxfuse puts itself into trap when it have to > keep and support all macfuse bugs in sake of backward compatibility with > macfuse. Fuse4x does not try to be fully backward compatible with macfuse, > instead it tries to be compatible with the upstream implementation.
> The fact is that macfuse/osxfuse is not compatible you can check by trying > to run following program https://gist.github.com/1101067 It runs perfectly > fine on the upstream Linux while hangs with macfuse/osxfuse.
> You might ask "What about existing programs that currently use macfuse? Do > they need to be recompiled?" If your filesystem works fine with MacFUSE just > continue using it - no need to do any changes. There is an unofficial build > from Tuxera that works fine with Lion. But if you care about being > compatible with the upstream fuse - use fuse4x. Applications that use fuse4x > can coexist with applications that use macfuse.
> The next release of fuse4x will add back some of the removed functions and > provide additional ABI compatible dylibs. It is needed to people who does > not want to use macfuse from Tuxera for some reason.
> FYI 2: there is an ongoing conversation with Miklos about merging >> MacFUSE/Fuse4X changes to the upstream project (don't forget that MacFUSE is >> a fork itself). It'll take some time though, at least a few months.
>> This would be the libfuse changes I assume. This would be much welcome, >> but please make sure that generic MacFUSE changes are merged and not changes >> that diverge between MacFUSE / FUSE4X / OSXFUSE (at least we need to agree >> between FUSE4X and OSXFUSE on pushing such changes upstream as it affects us >> both).
>> [1] Well, it won't be 100% compatible. Fuse4X has a few changes in fuse >> behavior (e.g. async mount(); fuse4x does not block SIGCHLD anymore; does >> not changes semaphores implementation from Darwin; has some >> de-initialization changes...). But assuming that the most filesystems are >> written for Linux (encfs, truecrypt, sshfs,...) with the upstream fuse >> behavior in mind it these changes will not break them. Even more - as Fuse4X >> follows standard closer these applications will work more stable and have >> less problems.
>> [2] It is still not clear to me the legal question around MacFUSE name. >> This brand belongs to Google and Amit explicitly asked not to use it so I am >> not sure if I can distribute/change MacFUSE.framework. So I need to clarify >> it with Google first or just wait until Google contacts and asks to >> remove MacFUSE.framework from the distribution package.
>> MacFUSE isn't really a registered trademark of either Amit or Google, is >> it? (I sincerely doubt that they would find MacFUSE to be worth protecting >> as a trademark.) >> It's not realistic to change all occurrences of 'MacFUSE' into something >> else, as this would mean that we have no chance of being compatible with >> existing software... especially in the case of MacFUSE.framework.
>> How far is the 'rebranding' expected to go? With this strict >> interpretation of brand ownership and usage we are all handcuffed when it >> comes to being compatible with existing binaries. >> (Amit is as always welcome to speak his mind... if he hasn't terminated >> his membership in this group.)
>> Regards,
>> - Erik
>> On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <flei...@gmail.com>wrote:
>>> Hi Josh,
>>> check out OSXFUSE. There has been some quite some messages in the past >>> about OSXFUSE on this mailinglist. >>> OSXFUSE is compatible with Leopard through Lion and features a >>> compatibility layer to be compatible with "all" existing MacFUSE filesystems >>> ("all" in: I could not test all, but OSXFUSE and MacFUSE are binary >>> compatible). Unlike Fuse4X the MacFUSE filesystems don't even have to be >>> recompiled! OSXFUSE is a drop-in replacement for MacFUSE.
>>> OSXFUSE has been build on Tuxera's rebel branch and my sources. Erik >>> (the author of the rebel branch) and I are the the owners of the OSXFUSE >>> project.
>>> You can find some instructions on building OSXFUSE in the group. If you >>> need assistance, feel free to ask. But please hold off from distributing any >>> builds. The update mechanism has not been set up and there are a few other >>> things I'm working on right now. Non the less OSXFUSE's core feature is >>> already fully functional.
>>> I will post an official beta in in the next two or three days. More >>> information to come. Just thought I'd let you know. We don't need another >>> MacFUSE fork/build around. The situation is already a mess as it is. But I >>> will highly appreciate you spreading the word when we are ready, in a few >>> days. You blog post has helped quite some people.
>>> Regards, >>> Benjamin
>>> Am 21.07.2011 um 07:02 schrieb Josh:
>>> Hello, I am the author of the blog post jb links to below. The direct >>> link to the page is here:
>>> I get many thank you comments from people, so I can only hope it helps >>> them. I can't take any credit for the work however, since I just >>> compiled Tuxera's 'rebel' source code.
>>> I am trying to figure out how to compile for Lion, and I've made some >>> progress, but so far I am stuck on a check in the build script, I'll >>> have to start understanding how it works I guess.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "MacFUSE" group. >>> To post to this group, send email to macfuse@googlegroups.com. >>> To unsubscribe from this group, send email to >>> macfuse+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/macfuse?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "MacFUSE" group. >> To post to this group, send email to macfuse@googlegroups.com. >> To unsubscribe from this group, send email to >> macfuse+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/macfuse?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "MacFUSE" group. >> To post to this group, send email to macfuse@googlegroups.com. >> To unsubscribe from this group, send email to >> macfuse+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/macfuse?hl=en.
fist of all let me say I'm sorry for going on about the whole OSXFUSE - Fuse4X situation. I think most of this stuff has already been discussed and this is getting to a rather personal level, but I felt the need to get some points straight. Feel free to skip this mail if you are not interested in the matter.
We had a rather lengthy discussion here in this group about the future of MacFUSE in May, I think. OSXFUSE originated from this discussion. It was agreed on that Erik's/Tuxera's 2.1.9 release should be the basis of the "official" MacFUSE successor, that it should be compatible with MacFUSE if possible and that it should support 10.5 through 10.7. The architectures to support have been a moot point. I took all these point to heart when I started working on OSXFUSE.
Anatol, you choose to leave the discussion prematurely to create Fuse4X behind closed doors. Most of us had not heard of Fuse4X until you announced the first release. That said, Anatol, I believe it's people acting like you who tear up open source projects.
You can find my comments below.
Regards Benjamin
Am 24.07.2011 um 08:08 schrieb Anatol Pomozov:
> On Thu, Jul 21, 2011 at 9:34 PM, Erik Larsson <catacom...@gmail.com> wrote: > Hi,
> Anatol Pomozov wrote 2011-07-22 02.33: >> FYI: The upcoming version of Fuse4X will include additional *.dylib files that are binary compatible with MacFUSE [1] so any application will work with Fuse4X without recompiling. Fuse4X is going to include compatible MacFUSE.framework as well [2].
> Ok, so what is the difference between OSXFUSE and FUSE4X now again? :)
> Fuse4X project exists for 1.5 months already, while OSXFUSE still not alive.
Fuse4X got a head start by leeching off Erik's code to support 64 bit kernels and my port of Linux libfuse 2.8.5 over to Mac OS X. Stay true to the facts. Without the work of others, namely the owners of the OSXFUSE project Fuse4X and you would not be where you are now. That is a fact.
In addition to that, unlike Fuse4X, I'm trying to get everything right into the first official release: MacFUSE compatibility, support for 10.5 through 10.7, ... This this a lot of work and takes some time.
> The technical differences that I remember from top of my head: > - fuse_mount operation made async. Without it fuse_mount() function is blocked until fuse daemon responses with FUSE_INIT. But in this case you cannot use low-level fuse API like this one: > fuse_mount(); fuse_new(); fuse_loop(); > - macfuse/osxfuse blocks SIGCHLD. This is just a horrible macfuse decision - you cannot use macfuse/osxfuse in multithread applications (wait() function does not work).
Well, we both know who fixed this problem. I't too bad that you deleted the repository with our length discussion. That's all I'm going to say to this one.
> - removed mount_fusefs binary. In linux and FreeBSD mount() syscall is privileged so one needs a binary with suid bit that user can use for mount(). Darwin does not need it - mount logic can be made much more simple and faster. > - uninitialization logic in macfuse is just horrible. fuse4x simplifies it and makes straight. > - a bunch of code cleanup in kext/libfuse > - public header macfuse_darwin.h in macfuse replaces semaphores with its own implementation based on pthreads (it is actually slightly changed libsem library from GNU Hurd). Fuse4x removes it as it is not a responsibility of the fuse library publicly replace Darwin core functionality. > - one more thing that I do not like in macfuse is fuse.pc vs fuse_i64.pc thing - macfuse (and I believe osxfuse) distributes 2 dynamic libraries, one for 32 another for 64 bit inodes. Instead one should use symbol variants. See more info here http://developer.apple.com/library/mac/#releasenotes/Darwin/SymbolVar...
OSXFUSE uses 64 bit inodes (libosxfuse links to libosxfuse_i64) but also comes with support for 32 bit inodes (libosxfuse_i32) which is mainly needed for MacFUSE compatibility. Mac OS X 10.5 through 10.7 default to 64 bit inodes anyway.
> OSXFuse is just rebranded Tuxera macfuse and nothing more. It is fully backward compatible with macfuse though, while fuse4x drops some functions and changed behavior described above.
The current state of OSXFUSE is a foundation for further development. The code of most core components is almost identical to Erik's release (2.1.9 and 2.2.0, but don't quote me on the last one) that seemed to work very well for a lot of people. I don't think it is an good development choice to change that much in an initial release, but that's just my opinion.
In addition to that OSXFUSE already features a MacFUSE compatibility layer/mode for MacFUSE file systems. This fact seems to have slipped you mind when you were listing the differences above.
Shortly after I uploaded the MacFUSE compatibility stuff you announced that you would "implement" something like that for Fuse4X, too. This is really getting ridiculous. But here you go, https://github.com/osxfuse/fuse/commit/dbf53e096209e90b1587eb0c38e1f2... is the link to the associated commit in the OSXFUSE repository. Might save you some time "implementing" the feature.
> Benjamin decided to follow "osxfuse is not fuse" way [1], while fuse4x follows "fuse4x *is* fuse". So osxfuse puts itself into trap when it have to keep and support all macfuse bugs in sake of backward compatibility with macfuse. Fuse4x does not try to be fully backward compatible with macfuse, instead it tries to be compatible with the upstream implementation.
I have never decided to follow the doctrine "OSXFUSE is not FUSE". In fact the mail you are referring to is from Jeff not me. My answer to that mail was: http://groups.google.com/group/macfuse/msg/8fdf902eb33bf17b. Please stop those false statements.
OSXFUSE does not trap itself. I have no idea how you come to this conclusion. OSXFUSE comes with two libraries libosxfuse and libmacfuse.
libmacfuse will stay compatible with the MacFUSE implementation where it is possible, while libosxfuse will be updated over time. For now since OSXFUSE uses libfuse 2.7.3 (as does MacFUSE) libmacfuse is nothing more than a wrapper for libosxfuse that enables the MacFUSE compatibility mode.
> The fact is that macfuse/osxfuse is not compatible you can check by trying to run following program https://gist.github.com/1101067 It runs perfectly fine on the upstream Linux while hangs with macfuse/osxfuse.
I'm not starting OSXFUSE off by using a newer but on Mac OS X untested version of libfuse. My first goal is to support the MacFUSE ecosystem. Compatibility with Linux is not all there is. From my point of view compatibility with MacFUSE comes first. Once that is achieved we will look at how things are done in Linux FUSE. This is what I have been saying since I started working on MacFUSE/OSXFUSE. Anatol, be my guest and look um those mails.
> You might ask "What about existing programs that currently use macfuse? Do they need to be recompiled?" If your filesystem works fine with MacFUSE just continue using it - no need to do any changes. There is an unofficial build from Tuxera that works fine with Lion. But if you care about being compatible with the upstream fuse - use fuse4x. Applications that use fuse4x can coexist with applications that use macfuse.
> The next release of fuse4x will add back some of the removed functions and provide additional ABI compatible dylibs. It is needed to people who does not want to use macfuse from Tuxera for some reason.
>> FYI 2: there is an ongoing conversation with Miklos about merging MacFUSE/Fuse4X changes to the upstream project (don't forget that MacFUSE is a fork itself). It'll take some time though, at least a few months.
> This would be the libfuse changes I assume. This would be much welcome, but please make sure that generic MacFUSE changes are merged and not changes that diverge between MacFUSE / FUSE4X / OSXFUSE (at least we need to agree between FUSE4X and OSXFUSE on pushing such changes upstream as it affects us both).
>> [1] Well, it won't be 100% compatible. Fuse4X has a few changes in fuse behavior (e.g. async mount(); fuse4x does not block SIGCHLD anymore; does not changes semaphores implementation from Darwin; has some de-initialization changes...). But assuming that the most filesystems are written for Linux (encfs, truecrypt, sshfs,...) with the upstream fuse behavior in mind it these changes will not break them. Even more - as Fuse4X follows standard closer these applications will work more stable and have less problems.
>> [2] It is still not clear to me the legal question around MacFUSE name. This brand belongs to Google and Amit explicitly asked not to use it so I am not sure if I can distribute/change MacFUSE.framework. So I need to clarify it with Google first or just wait until Google contacts and asks to remove MacFUSE.framework from the distribution package.
> MacFUSE isn't really a registered trademark of either Amit or Google, is it? (I sincerely doubt that they would find MacFUSE to be worth protecting as a trademark.) > It's not realistic to change all occurrences of 'MacFUSE' into something else, as this would mean that we have no chance of being compatible with existing software... especially in the case of MacFUSE.framework.
> How far is the 'rebranding' expected to go? With this strict interpretation of brand ownership and usage we are all handcuffed when it comes to being compatible with existing binaries. > (Amit is as always welcome to speak his mind... if he hasn't terminated his membership in this group.)
> Regards,
> - Erik
>> On Thu, Jul 21, 2011 at 1:30 AM, Benjamin Fleischer <flei...@gmail.com> wrote: >> Hi Josh,
>> check out OSXFUSE. There has been some quite some messages in the past about OSXFUSE on this mailinglist. >> OSXFUSE is compatible with Leopard through Lion and features a
> On the 64bit machines, it seems the images are regularly unmounted
> without notice.
[...]
> Do you guys use 64bit macs? Have you encountered the same problems?
I am seeing the same thing with OSXFUSE 2.3 and EncFS 1.7.4 on Lion 64
- I also found this ticket: https://trac.macports.org/ticket/30129 which suggests there might be a solution by Apple (?!).
Sorry for the late responses, I've been away on holiday for 2 weeks.
For clarification:
I tested MacFuse 2.1.7 (somewhat 64bit compatible).
I tested MacFuse 2.1.9 (Tuxera version, which I believe is now called
OSXFuse?)
I tested Fuse4x
They all have this problem with EncFS.
I switched to another filesystem on top of MacFuse 2.1.9 (probably
moving to Fuse4X soon), as I could not get this resolved. Only EncFS
seems to have this problem, even though they claim that it is caused
by MacFuse, and every filesystem should encounter it. Perhaps they
just use a macFUSE function no one else does.
This is a bugreport, please keep the MacFuse/OSXFuse/Fuse4x name
changes/forks/... discussions out of this thread....
thanks,
- Kenny
On Jul 28, 1:29 am, Joscha Feth <jos...@feth.com> wrote:
> > On the 64bit machines, it seems the images are regularly unmounted
> > without notice.
> [...]
> > Do you guys use 64bit macs? Have you encountered the same problems?
> I am seeing the same thing with OSXFUSE 2.3 and EncFS 1.7.4 on Lion 64
> - I also found this ticket:https://trac.macports.org/ticket/30129 > which suggests there might be a solution by Apple (?!).
> Sorry for the late responses, I've been away on holiday for 2 weeks.
> For clarification:
> I tested MacFuse 2.1.7 (somewhat 64bit compatible).
> I tested MacFuse 2.1.9 (Tuxera version, which I believe is now called
> OSXFuse?)
> I tested Fuse4x
> They all have this problem with EncFS.
> I switched to another filesystem on top of MacFuse 2.1.9 (probably
> moving to Fuse4X soon), as I could not get this resolved. Only EncFS
> seems to have this problem, even though they claim that it is caused
> by MacFuse, and every filesystem should encounter it. Perhaps they
> just use a macFUSE function no one else does.
> This is a bugreport, please keep the MacFuse/OSXFuse/Fuse4x name
> changes/forks/... discussions out of this thread....
> thanks,
> - Kenny
> On Jul 28, 1:29 am, Joscha Feth <jos...@feth.com> wrote:
> > > On the 64bit machines, it seems the images are regularly unmounted
> > > without notice.
> > [...]
> > > Do you guys use 64bit macs? Have you encountered the same problems?
> > I am seeing the same thing with OSXFUSE 2.3 and EncFS 1.7.4 on Lion 64
> > - I also found this ticket:https://trac.macports.org/ticket/30129 > > which suggests there might be a solution by Apple (?!).
Did you also see this with EncFS, or other filesystems? (I'm assuming
Expandrive uses a filesystem like SshFS?)
The problem I encountered also occurs on Snow Leopard 64 bit edition,
It really seems to be caused by the switch to 64 bit, not necessarily
Lion (even though Lion uses 64bit as default now).
regards,
- Kenny
On Aug 3, 4:13 pm, Jeff Mancuso <jmanc...@expandrive.com> wrote:
> We're also seeing Lion flake out and lose communication from a variety
> of users.
> Erik/Ben/Anatol - have you see this one in action?
> -Jeff
> On Aug 1, 5:10 am, Kenny <psyki...@gmail.com> wrote:
> > Hi,
> > Sorry for the late responses, I've been away on holiday for 2 weeks.
> > For clarification:
> > I tested MacFuse 2.1.7 (somewhat 64bit compatible).
> > I tested MacFuse 2.1.9 (Tuxera version, which I believe is now called
> > OSXFuse?)
> > I tested Fuse4x
> > They all have this problem with EncFS.
> > I switched to another filesystem on top of MacFuse 2.1.9 (probably
> > moving to Fuse4X soon), as I could not get this resolved. Only EncFS
> > seems to have this problem, even though they claim that it is caused
> > by MacFuse, and every filesystem should encounter it. Perhaps they
> > just use a macFUSE function no one else does.
> > This is a bugreport, please keep the MacFuse/OSXFuse/Fuse4x name
> > changes/forks/... discussions out of this thread....
> > > > On the 64bit machines, it seems the images are regularly unmounted
> > > > without notice.
> > > [...]
> > > > Do you guys use 64bit macs? Have you encountered the same problems?
> > > I am seeing the same thing with OSXFUSE 2.3 and EncFS 1.7.4 on Lion 64
> > > - I also found this ticket:https://trac.macports.org/ticket/30129 > > > which suggests there might be a solution by Apple (?!).
> Did you also see this with EncFS, or other filesystems? (I'm assuming
> Expandrive uses a filesystem like SshFS?)
> The problem I encountered also occurs on Snow Leopard 64 bit edition,
> It really seems to be caused by the switch to 64 bit, not necessarily
> Lion (even though Lion uses 64bit as default now).
> regards,
> - Kenny
> On Aug 3, 4:13 pm, Jeff Mancuso <jmanc...@expandrive.com> wrote:
> > We're also seeing Lion flake out and lose communication from a variety
> > of users.
> > Erik/Ben/Anatol - have you see this one in action?
> > -Jeff
> > On Aug 1, 5:10 am, Kenny <psyki...@gmail.com> wrote:
> > > Hi,
> > > Sorry for the late responses, I've been away on holiday for 2 weeks.
> > > For clarification:
> > > I tested MacFuse 2.1.7 (somewhat 64bit compatible).
> > > I tested MacFuse 2.1.9 (Tuxera version, which I believe is now called
> > > OSXFuse?)
> > > I tested Fuse4x
> > > They all have this problem with EncFS.
> > > I switched to another filesystem on top of MacFuse 2.1.9 (probably
> > > moving to Fuse4X soon), as I could not get this resolved. Only EncFS
> > > seems to have this problem, even though they claim that it is caused
> > > by MacFuse, and every filesystem should encounter it. Perhaps they
> > > just use a macFUSE function no one else does.
> > > This is a bugreport, please keep the MacFuse/OSXFuse/Fuse4x name
> > > changes/forks/... discussions out of this thread....
> > > > > On the 64bit machines, it seems the images are regularly unmounted
> > > > > without notice.
> > > > [...]
> > > > > Do you guys use 64bit macs? Have you encountered the same problems?
> > > > I am seeing the same thing with OSXFUSE 2.3 and EncFS 1.7.4 on Lion 64
> > > > - I also found this ticket:https://trac.macports.org/ticket/30129 > > > > which suggests there might be a solution by Apple (?!).
