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

os: TestLongPath failing on Plan 9 #17855

Closed
0intro opened this issue Nov 8, 2016 · 5 comments
Closed

os: TestLongPath failing on Plan 9 #17855

0intro opened this issue Nov 8, 2016 · 5 comments
Assignees
Milestone

Comments

@0intro
Copy link
Member

@0intro 0intro commented Nov 8, 2016

CL 32451 added TestLongPath. However this test is failing on Plan 9.

--- FAIL: TestLongPath (1.13s)
	os_test.go:1750: Size("/tmp/_Go_TestLongPath893630335/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/dir3456789/bar.txt") is 0, len(ReadFile()) is 12, want 0
FAIL

See https://build.golang.org/log/6d7b8caa753adbea2d9c4520296ead1e88ab94d2

@0intro 0intro added the OS-Plan9 label Nov 8, 2016
@0intro 0intro added this to the Go1.8Maybe milestone Nov 8, 2016
@0intro 0intro self-assigned this Nov 8, 2016
@0intro

This comment has been minimized.

Copy link
Member Author

@0intro 0intro commented Nov 8, 2016

The problem is that after the call to Truncate(tmpdir+"/bar.txt", 0) in TestLongPath, the file is zero sized, but the content is still accessible.

% ls -l _Go_TestLongPath462655911/bar.txt
--rw------- M 12853 djc djc 0 Nov  8 22:06 _Go_TestLongPath462655911/bar.txt
% cat _Go_TestLongPath462655911/bar.txt
hello world
% echo a >>_Go_TestLongPath462655911/bar.txt
% cat _Go_TestLongPath462655911/bar.txt
a

If we replace the call of Truncate(tmpdir+"/bar.txt", 0) by OpenFile(tmpdir+"/bar.txt", O_TRUNC, 0), the test succeeds.

The problem seems to only happen on the Fossil file server and not on ramfs or cwfs.

@quentinmit

This comment has been minimized.

Copy link
Contributor

@quentinmit quentinmit commented Nov 9, 2016

That seems like a Plan9 bug, no? If truncate doesn't work, the test is correctly failing...

@0intro

This comment has been minimized.

Copy link
Member Author

@0intro 0intro commented Nov 9, 2016

Yes, it seems to be an issue related to the Fossil file server. I'll investigate.

@0intro

This comment has been minimized.

Copy link
Member Author

@0intro 0intro commented Nov 9, 2016

This issue is caused by the devmnt cache in the Plan 9 kernel.

The file content is cached when writing the file. When reading the file, the content is firstly read from the cache (12 bytes), then the remaining is read from the file server (offset=12 > length=0, so 0 bytes). So devmnt, returns the 12 bytes "hello world" from the cache. This is happening because the call to wstat, which sets the file length to zero, doesn't invalidate the cache.

The fix would probably be to invalidate the cache on wstat when setting the length to zero.

I can reproduce the issue with other file servers like ramfs by mounting with the cache enabled (-C).

@0intro

This comment has been minimized.

Copy link
Member Author

@0intro 0intro commented Nov 10, 2016

I've finally fixed the issue in the Fossil server by incrementing Qid.vers on wstat, so the next read will be done on a new version of the file instead of the cached one.

Here is the change: fossil-wstat-qid

@0intro 0intro closed this Nov 10, 2016
@golang golang locked and limited conversation to collaborators Nov 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.