Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upWith attr_timeout all files are empty at first read #192
Comments
This comment has been minimized.
This comment has been minimized.
|
Which file system are you observing the issue with? Are you by any chance using mount-time option |
This comment has been minimized.
This comment has been minimized.
|
I'm using proprietary filesystem written in D (it's using dfuse bindings to connect with fuse https://github.com/facebook/dfuse ). My options are: |
This comment has been minimized.
This comment has been minimized.
|
Thanks! I have fixed a bug that is most likely responsible for the observed getattr issue in osxfuse 2.7.3 and 2.7.4. It would be great if you could test the following osxfuse build and confirm that the issue is indeed gone: http://sourceforge.net/projects/osxfuse/files/osxfuse-2.7.5/osxfuse-2.7.5.dmg/download |
This comment has been minimized.
This comment has been minimized.
|
Everything works as expected. Thank you! :) |
When creating a vnode its cached attributes are not initialized, therefore the vnode's attr_valid field should be zero instead of attr_timout. Tracked as issue #192: osxfuse/osxfuse#192
When creating a vnode its cached attributes are not initialized, therefore the vnode's attr_valid field should be zero instead of attr_timeout. See osxfuse/osxfuse#192 for details
Before first read of the file stat always returns all-zero structure which is resulting in all files having size 0 in the first read. After first read of a file everything works just fine for it.
The problems seems to be a problem with att_timeout . When it's off on stat fuse is making two calls to getattr and stat syscall is returning correct numbers. For example:
$ stat -r file
1291845653 7 0100555 0 0 0 0 37344190 0 0 0 0 65536 72944 4294967295 file
When it's on only one call to getattr is done and stat syscall is returning almost all-zero stuct:
$ stat -r file
1325400088 0 0100000 0 0 0 0 0 0 0 0 0 0 0 0 file
The bug appeared in version of 2.7.3 of the kernel module. Version 2.7.2 works just fine.