Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests in memnode_test.go don't actually use memNode on OS X (!) #44

Closed
akalin opened this issue Apr 24, 2015 · 2 comments
Closed

Tests in memnode_test.go don't actually use memNode on OS X (!) #44

akalin opened this issue Apr 24, 2015 · 2 comments

Comments

@akalin
Copy link
Contributor

akalin commented Apr 24, 2015

Repro steps:

  1. Put a panic in memNode.Create() (or other callers of newNode() or newFile()).
  2. Run go test with -run MemNodeFsWrite

I expect the panic to be hit (as it is in Linux) but it's not. Various other things that I'd expect to be hit are also not hit.

I'm not sure exactly why this happens. My working hypothesis is that OSXFUSE sends does an ACCESS call, which returns a "not implemented" error, and it gets confused by that and doesn't actually do the mount.

Log below:

=== RUN TestMemNodeFsWrite
2015/04/23 17:23:34 Dispatch: INIT, NodeId: 0. data: *fuse.InitIn: {7.8 Ra 0x100
00 } 
2015/04/23 17:23:34 Serialize: INIT code: OK value: {7.8 Ra 0x10000  9/12 Wr 0x10000}
2015/04/23 17:23:34 Dispatch: STATFS, NodeId: 1. 
2015/04/23 17:23:34 Serialize: STATFS code: OK value: {blocks (0,0)/0 files 0/0 
bs0 nl0 frs0}
2015/04/23 17:23:34 Dispatch: STATFS, NodeId: 1. 
2015/04/23 17:23:34 Serialize: STATFS code: OK value: {blocks (0,0)/0 files 0/0 
bs0 nl0 frs0}
2015/04/23 17:23:34 Dispatch: STATFS, NodeId: 1. 
2015/04/23 17:23:34 Serialize: STATFS code: OK value: {blocks (0,0)/0 files 0/0
(lots of STATFS calls)
2015/04/23 17:23:34 Dispatch: ACCESS, NodeId: 1. data: {} 
2015/04/23 17:23:34 Serialize: ACCESS code: 78=function not implemented value: 
2015/04/23 17:23:34 Dispatch: GETATTR, NodeId: 1. data:  
2015/04/23 17:23:34 Serialize: GETATTR code: OK value: {A0.100000000 {M040777 SZ
=0 L=0 0:0 0 0:1 A 1429835014.567037062 M 1429835014.567037062 C 1429835014.5670
37062}}
(more STATFS and LOOKUP calls (for "._.")
@hanwen
Copy link
Owner

hanwen commented Apr 24, 2015

the other possiblity is that StatFS should return more credible values. The loopback tests are run on top of PathFS which stacked on a NodeFS, so it should be possible to make work. You could run the loopback tests (fuse/test) and see what they return .

@hanwen
Copy link
Owner

hanwen commented Jul 29, 2016

I think this may just be a race condition: the writes complete on the normal filesystem before the mount point is available.

please reopen if this still happens with current HEAD.

@hanwen hanwen closed this as completed Jul 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants