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.

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

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

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).

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