Fix building on FreeBSD

[zaynetro]

Closes owncloud/ocis#1217

• Extracted common error methods to errtypes package
• Fixed type error on Bavail ( https://golang.org/src/syscall/ztypes_freebsd_arm64.go#L125 )
• Alias ENODATA to ENOATTR

Still pending:

• I am not sure how to implement error methods on Windows
• Wait for https://github.com/c-bata/go-prompt to depend on not-yet-released 1.2.0 version of https://github.com/pkg/term
  • term fixed the build issues recently termios/pty_freebsd.go:10:15: undefined: unix pkg/term#57

How to test this on Linux:

export GOOS=freebsd
make

UPD: go-prompt patched c-bata/go-prompt#224 (waiting for a release)

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[zaynetro]

Hmm,

pkg/storage/fs/ocis/ocis_unix.go:31:18: unnecessary conversion (unconvert)
    bavail := uint64(stat.Bavail) // stat.Bavail is int64 on FreeBSD

will be nice to somehow enable -all flag on unconvert linter (ref: https://github.com/mdempsky/unconvert )

Using the -all flag, unconvert will analyze the Go packages under all possible GOOS/GOARCH combinations, and only identify conversions that are unnecessary in all cases.

E.g., syscall.Timespec's Sec and Nsec fields are int64 under linux/amd64 but int32 under linux/386. An int64(ts.Sec) conversion that appears in a linux/amd64-only file will be identified as unnecessary, but it will be preserved if it occurs in a file that's compiled for both linux/amd64 and linux/386.

golang-ci uses a fork https://github.com/golangci/unconvert

[zaynetro]

OK. Now only need to figure out how to resolve unconvert lint issue golangci/golangci-lint#1809

Let me know if you have some ideas.

[ishank011]

Hi @zaynetro, thanks for the PR, the changes look good! We can wait for you to implement the changes in unconvert or golangci-lint. If that takes long to merge, we can also have separate the implementations for ocis_unix and ocis_freebsd.

[zaynetro]

Seems like it will take a while to update golangci-lint so I split into more freebsd specific files as you suggested.

[zaynetro]

@ishank011 How can we continue with these changes?

[ishank011]

@zaynetro apologies for the delay. Mostly looks good. Windows syscalls do have the ENODATA error https://golang.org/src/syscall/zerrors_windows.go. Can we use that?

[ishank011]

Can you revert the go-prompt upgrade? There were issues with user input with 0.2.6

[zaynetro]

go-prompt update is necessary because it fixes other build errors: c-bata/go-prompt#224.

I will take a look at Windows implementation for error handling.

[ishank011]

Ah okay. Will try fixing it

[zaynetro]

zerrors_windows.go has a comment above defined contants.

// Invented values to support what package os and others expects.

Also syscall package is deprecated

Deprecated: this package is locked down. Callers should use the corresponding package in the golang.org/x/sys repository instead.

I am not sure that Windows has exact same errors as unix systems. golang.org/x/sys/windows defines completely different error types. Do you still want me to implement XattrIsNoData method on Windows using syscall.ENODATA constant? I am not familiar with file systems but to me it seems that ENODATA will never happen on Windows since there is no such thing there.

[ishank011]

@zaynetro ah okay, we can let it be then. Can you rebase?

[zaynetro]

Done.

[butonic]

@zaynetro could you rebase? I think @ishank011 would like to get this in.

[zaynetro]

Rebased.

[butonic]

@micbar you had a look at the ENOATTR ENODATA and sent an upstream PR https://github.com/pkg/xattr/pull/63/files
@C0rby don't you have a bsd variant running?

I know this PR bitrotted a bit, still @zaynetro could you retarget this PR against the edge branch? It might be easier to get it in there.

[Lars-Cleemann]

Is there any update on this bug?
OCIS still does not build on FreeBSD due to this bug.

[micbar]

oCIS is now building on the edge branch which means it uses reva 2.x releases.

This fix would need to go to the edge branch.

[joramkruijer]

Is there any update on this bug?
OCIS still does not build on FreeBSD due to this bug.

I've just attempted to build oCIS v2.0.0 (their stable release) on FreeBSD today and can confirm this bug is still present in reva, preventing a successful compilation.. What can I do to help speed this up?

[micbar]

@joramkruijer please try the latest master.

[joramkruijer]

@joramkruijer please try the latest master.

Thanks, that resolves the compilation issue! There's an issue preventing ocis from running due to a bug in reva, for which I've opened a pull request (#3650).