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

Plan 9 Support #52

Open
henesy opened this issue Feb 21, 2018 · 3 comments · May be fixed by #78
Open

Plan 9 Support #52

henesy opened this issue Feb 21, 2018 · 3 comments · May be fixed by #78

Comments

@henesy
Copy link

henesy commented Feb 21, 2018

Getting Billy (osfs) to build on Plan 9 is possible by adding the following:

osfs/os_plan9.go

// +build plan9

package osfs

import (
	"os"
)

func (f *file) Lock() error {
	f.m.Lock()
	defer f.m.Unlock()

	s, err := f.Stat()
	if(err != nil) {
		return err
	}

	// Add exclusive bit
	return (f.File).Chmod(s.Mode() | os.ModeExclusive)
}

func (f *file) Unlock() error {
	f.m.Lock()
	defer f.m.Unlock()

	s, err := f.Stat()
	if(err != nil) {
		return err
	}

	// Remove exclusive bit
	return (f.File).Chmod(s.Mode() & ^os.ModeExclusive)
}

I changed osfs/os_posix.go's build header to the following, but I'm not sure it's necessary:

// +build !windows,!plan9
@mcuadros
Copy link
Contributor

will be great if you can do a PR

@fhs
Copy link

fhs commented Dec 7, 2019

@henesy I think Lock is supposed to block until it acquires the lock (the posix implementation doesn't use LOCK_NB with flock). Maybe we can do something similar to the lockedfile package used by cmd/go.

Go's internal/filelock package does not support Plan 9.

@fhs
Copy link

fhs commented Dec 11, 2019

I'll be sending a PR for Plan 9 support soon.

It's not really possible to implement Lock/Unlock using the "exclusive use" bit:

Per http://man.cat-v.org/plan_9/5/stat: “Exclusive use files may be open
for I/O by only one fid at a time across all clients of the server. If a
second open is attempted, it draws an error.”

Since Lock is called on an open file, if we can't open a locked file in the first place, we never even get into the Lock function to wait for the file to be unlocked by the other client. I think go-billy will need to use an API similar to the lockedfile package to support file locking on Plan 9.

I got all the tests passing on Plan 9, but I found that running go test ./... hangs in TestTempFileMany and TestTempFileManyWithUtil if we're using test cache. This is possibly a go tool bug. If I run the tests with go test -count 1 ./... everything passes.

fhs added a commit to fhs/go-billy that referenced this issue Dec 12, 2019
Fixes src-d#52

Signed-off-by: Fazlul Shahriar <[email protected]>
fhs added a commit to fhs/go-billy that referenced this issue Dec 12, 2019
Fix build on Plan 9 and make all tests pass.

Note: running `go test ./...` may hang in `TestTempFileMany` or
`TestTempFileManyWithUtil`. I'm not sure if it's a go tool issue,
standard library issue, or something wrong with the tests.  All tests
pass if tests are run with `go test -count 1 ./...`.

Fixes src-d#52

Signed-off-by: Fazlul Shahriar <[email protected]>
@fhs fhs linked a pull request Dec 12, 2019 that will close this issue
fhs added a commit to fhs/go-billy that referenced this issue Dec 12, 2019
Fix build on Plan 9 and make all tests pass.

Note: running `go test ./...` may hang in `TestTempFileMany` or
`TestTempFileManyWithUtil`. I'm not sure if it's a go tool issue,
standard library issue, or something wrong with the tests.  All tests
pass if tests are run with `go test -count 1 ./...`.

Fixes src-d#52

Signed-off-by: Fazlul Shahriar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants