Reconsider exposing the underlying file handle

[klarose]

Thanks for the great package. It has solved quite a few challenges for me. That said, I recently ran into something and I'm in a bit of a bind without having access to the file handle held by the Flock object.

I understand from other conversations in the issues that the main purpose of this library is to support lock-file based locking, rather than locking the file you intend on modifying. That is a great solution when all parties involved in modifying the file agree on the strategy. However, I need to integrate with some software on Windows which does not use that approach: it simply locks the file it intends on modifying. As mentioned elsewhere, windows locking strategy limits what you can do: you can really only operate on the file handle that was used to create the lock.

I get why it's good to keep the interface pure so that users are lead to the lock-file approach. However, this package is the best os-independent golang file locking library I've found; none of the others really measure up to it. It'd be a shame to have to reimplement so much of it just to access its internal file handle.

For now, I've forked the repo until I can come up with a better strategy (I'm under somewhat of a time crunch). That said, if there is interest in actually doing this work, we could consider starting a PR with my commit. Alternatively, I'm willing to work to add other solutions as long as they satisfy my key requirement of being able to perform operations on the os.File underlying the lock.

[tilakraj9560]

can we have this? prob we might want to pass the underlying file descriptors for some other use or to some other process to sync. its totally absurd that there's no way to get the underlying info about the lockfile.