solving mac compilation errors, but there are still testing errors

Issue #59 closed
Anonymous created an issue

Initially I have got several errors from installation of tmsu to mac.

$ go get hanwen/go-fuse/fuse/server_darwin.go:9: undefined: Write hanwen/go-fuse/fuse/splice_darwin.go:11: *ReadResultFd is not a type mount_darwin.go:124: cannot use nil as type int in return argument mount_darwin.go:126: cannot use fd (type as type int in return argument

The first error line 9 , err := syscall.Write(ms.mountFd, Write(header)) is fixed by 9 , err := syscall.Write(ms.mountFd, header)

The second error line 11 func (ms Server) trySplice(header []byte, req request, fdData ReadResultFd) error { is fixed by 11 func (ms Server) trySplice(header []byte, req request, fdData readResultFd)

the third error line 124 return nil, mountError(C.GoString(errp)) is fixed by 124 return 0, mountError(C.GoString(errp))

The fourth line 126 return fd, nil is fixed by 126 return int(fd), mountError(C.GoString(nil))

After resolving them, I got the following error messages to build it: go build -o tmsu tmsu src/tmsu/vfs/fusevfs.go:23:2: found packages pathfs (api.go) and fuse (loopback_darwin.go) in /Users/yijun/gopath/src/ make: *** [compile] Error 1

These are fixed by changing hanwen/go-fuse/fuse/pathfs/loopback_darwin.go 1 package fuse to 1 package pathfs

Then the make errors are: ../../../gopath/src/ cannot use loopbackFile literal (type loopbackFile) as type File in return argument: loopbackFile does not implement File (missing Allocate method) ../../../gopath/src/ input.NodeId undefined (type fuse.GetAttrIn has no field or method NodeId) ../../../gopath/src/ input.Context undefined (type fuse.GetAttrIn has no field or method Context) ../../../gopath/src/ input.NodeId undefined (type *fuse.GetAttrIn has no field or method NodeId)

The first error can be resolved by

cp ../../../gopath/src/ ../../../gopath/src/ and modify line 12 err := syscall.Fallocate(int(f.File.Fd()), mode, int64(off), int64(sz)) with 12 err := syscall.Ftruncate(int(f.File.Fd()), int64(sz));

The other errors can be fixed by:

../../../gopath/src/ add the following lines to the empty GetAttrIn struct:

54 InHeader 55 56 Flags_ uint32 57 Dummy uint32 58 Fh_ uint64

../../../gopath/src/ undefined: LoopbackFileSystem ../../../gopath/src/ undefined: StatfsOut ../../../gopath/src/ undefined: StatfsOut

../../../gopath/src/ change LoopbackFileSystem to loopbackFileSystem

Add the following line to import statement: "" then add "fuse." before the use of StatfsOut struct


Now the system compiles, but there are the following test errors [2 1 3] --- FAIL: TestStatusReport (0.02 seconds) common_test.go:41: Output was not as expected. Expected: tmsu: New tag 'a'.\ntmsu: New tag 'b'.\ntmsu: New tag 'd'.\nT /tmp/tmsu/a\nM /tmp/tmsu/b\n! /tmp/tmsu/d\nU /tmp/tmsu/c\n Actual: tmsu: New tag 'a'.\ntmsu: New tag 'b'.\ntmsu: New tag 'd'.\nT /tmp/tmsu/a\nT /tmp/tmsu/b\n! /tmp/tmsu/d\nU /tmp/tmsu/c\n FAIL FAIL tmsu/cli/commands 0.456s ? tmsu/common [no test files] ? tmsu/common/proc [no test files] ok tmsu/fingerprint 0.030s ? tmsu/log [no test files] ok tmsu/path 0.023s ? tmsu/storage [no test files] ? tmsu/storage/database [no test files] ? tmsu/vfs [no test files] make: *** [test] Error 1

My guess is the Allocate was not implemented correctly.

Comments (3)

  1. Paul Ruane repo owner

    Sorry for not getting back to you sooner. Wanted to properly understand your email first.

    The go-fuse errors you should report to the go-fuse project: so they can be included in subsequent releases of that package.

    The test errors are a bit stranger. At first I assumed they would be line end differences between the platforms but it appears that there is actually a functional difference with your build not detecting modifications to files, which is odd as the 'status' command looks at both the file size and modification time.

    M /tmp/tmsu/b
    T /tmp/tmsu/b

    Having looked at the test case, it appears I'm recreating the file with the same contents which suggests that your build is detecting the modification date to be the same for the newly created file. Perhaps there is a bug or platform limitation with file modification dates.

    Could you please try the following:

    1. Open tmsu/src/tmsu/cli/commands/status_test.go in an editor.
    2. On line 78, where file 'b' is recreated after it is deleted, could you change the second parameter of 'createFile' that specifies the files contents to something longer, e.g. 'b2'.
    3. Rerun the test.

    If the test is now successful that would strongly suggest your build is erroneously reporting file modification times for whatever reason.

    If you wish, you can dump out the actual modification times that are being compared by modifying tmsu/src/tmsu/cli/commands/status.go:

    1. Line 282 is where the file size and modification time are compared, so insert a line before that:

      fmt.Println("File size", stat.Size(), "DB size", file.Size, "File mod", stat.ModTime().UTC(), "DB mod", file.ModTime)

    I would be interested to see the result of this.

    Many thanks, Paul.

  2. Log in to comment