nightlyone / lockfile Goto Github PK

hello, this is probably because of my inexperience with go, but when I do go get github.com/nightlyone/lockfile it says package github.com/nightlyone/lockfile imports github.com/nightlyone/lockfile: import cycle not allowed
thanks aot

See comments.

Have you considered adding automatic retries when obtaining the lock? I feel like it's a common enough use case where you want to wait for another process to finish before you try to access the lock. Personally, I would see it as a separate function (maybe RetryLock(retries int, sleep time.Duration))

I currently have a use-case where I need a non-recursive lock so that two subsequent lock.TryLock()s wouldn't succeed. Would you accept a patch extending the semantics? I imagine a boolean switch in Lockfile that can be used when comparing the PID of the lock owner and the current one.

The motivation for the pull-request #13 from @yqylovy described an interesting observation:

when process is executing the TryLock() and another process Unlock(),the process will return a no such file or directory error

It should return a specific error here and suggest a retry. And maybe also suggest a retry in other places.

Can this library be used to prevent an external program from deleting or modifying an external program while I try and run the external program using os.Exec()?

os: windows (tested on win10)

Reproduce:

1. Create lock file.
2. Exit process without cleaning up lock file. (as happens when you crash)
3. TryLock from new process.

This will produce OpenProcess: The parameter is incorrect. error, when it should succeed.

Cause:

func (l Lockfile) GetOwner() (*os.Process, error) {
    ...
        p, err := os.FindProcess(pid)
        if err != nil {
            return nil, err
        }
    ...
}

https://golang.org/pkg/os/#FindProcess

On Unix systems, FindProcess always succeeds and returns a Process for the given pid, regardless of whether the process exists.

But it's not documented for windows, and appears to return the error when process does not exit.

Fix:

We can assume that if the process exists, then FindProcess always succeeds in any operating system. There for, if FindProcess process returns an error, the process does not exist. So instead of returning the err, return ErrInvalidPid or ErrDeadOwner sould work here.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

The lockfile won't be deleted when my program crash.
And the pid in the lockfile may be reused by other process(not my program).
Then my program will be locked failed unless delete the lockfile.
System: Windows

Can lockfile check process name or path by pid ?

Without the specific atomicity guarantees of setting a hard link and rename a file in a directory the whole locking beaks. I could be more friendly to the users by documenting these constraints better and being more specific about which errors I ignore.

Also fail properly on unexpected errors when creating the hardlink.

README.md says the project has a BSD license, but the contents of the LICENSE file match the MIT license. Can you help clarify?

See the following issue in go dep:

golang/dep#947

Would it be reasonable to try os.SymLink() if os.Link() fails?

Hello,
first off, thanks for your library! While working on a project that uses it, I found (u-root/u-root#954) that lockfile uses hard links, and this fails if the source and the destination files are on different mount points. Hard links are not really necessary on UNIX platforms for locking purposes. If that sounds OK I will send a PR to use symlinks if the platform is a UNIX system. Thanks!

cc @hugelgupf @rminnich