Any chance you would be willing to license this file under a permissive
license such as MIT/ISC?

http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/xpdev/filewrap.c?view=markup

I'm trying to get file-range locking support into libuv/node.js so that it
can work with record locking files.

https://github.com/libuv/libuv/issues/318 https://github.com/nodejs/node/issues/1426
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

Re: Source Request
By: tracker1 to Digital Man on Mon Nov 16 2015 01:51 am

Any chance you would be willing to license this file under a permissive license such as MIT/ISC?

http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/xpdev/filewrap.c?view=markup

I'm trying to get file-range locking support into libuv/node.js so that it can work with record locking files.

LGPL isn't permissive enough?

Anyway, if you seriously think it'll be used, I have no problem ammending the license or dual-licensing or whatever.

digital man

Synchronet "Real Fact" #58:
Synchronet apparel and merchandise can be purchased at cafepress.com/synchronet Norco, CA WX: 51.2øF, 56.0% humidity, 11 mph ESE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Source Request
By: tracker1 to Digital Man on Mon Nov 16 2015 01:51 am

Any chance you would be willing to license this file under a permissive license such as MIT/ISC?

http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/xpdev/filewrap.c?view=markup

It's already LGPL... and that code has stuff that's fairly specific to my system (my F_SANERDLCKNO patch was never accepted into FreeBSD).

Pulling that in to something else that's not based around the DOS share modes would be a mistake IMHO. Synchronet has a long history of using SHARE stuff, so it makes sense to emulate that on other OSs. This likely does NOT make sense for libuv.

That said, I'm not opposed to adding a license to that stuff.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Any chance you would be willing to license this file under a permissive license such as MIT/ISC?

http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/xpdev/filewrap.c?view=mark up

I'm trying to get file-range locking support into libuv/node.js so that it can work with record locking files.

LGPL isn't permissive enough?

Anyway, if you seriously think it'll be used, I have no problem ammending the license or dual-licensing or whatever.

libuv isn't (L)GPL, so even looking at the source beyond
the license at the top could be considered to be tainting
the project in question.

libuv is the cross-platform I/O library that's at the core of
node.js (which is runtime bindings from libuv to v8)...
Unfortunately libuv doesn't have dynamic locking (flock)
let alone range locking (fcntl) only exclusive read/write
as an option.

Honestly, I'm planning on trying to get this working
myself this weekend, and will see what I can come
up with.. my knowledge of C is way old and nearly
non-existant.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

It's already LGPL... and that code has stuff that's fairly specific to my system (my F_SANERDLCKNO patch was never accepted into FreeBSD).

As stated in a prior message LGPL is incompatible for use as source in
many other licensed projects. I was only pointing to it as a reference.

Pulling that in to something else that's not based around the DOS share modes would be a mistake IMHO. Synchronet has a long history of using SHARE stuff, so it makes sense to emulate that on other OSs. This likely does NOT make sense for libuv.

Fair enough, but isn't range locking important to interoperate
with different programs (such as synchronet)? If I use node's
shared read/write access and don't do any locking, won't
things potentially mess up?

For reference:
https://github.com/nodejs/node/issues/1426 https://github.com/libuv/libuv/issues/318

I'm going to try to get this in myself over the weekend,
no idea if I'll succeed or not, but going to try. I really
don't know C.

--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

Re: Re: Source Request
By: tracker1 to Digital Man on Tue Nov 17 2015 07:20 pm

Any chance you would be willing to license this file under a permissive license such as MIT/ISC?

http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/xpdev/filewrap.c?view=m ark up

I'm trying to get file-range locking support into libuv/node.js so that it can work with record locking files.

LGPL isn't permissive enough?

Anyway, if you seriously think it'll be used, I have no problem ammending the license or dual-licensing or whatever.

libuv isn't (L)GPL, so even looking at the source beyond
the license at the top could be considered to be tainting
the project in question.

The whole point of LGPL is to be able to create libraries (like xpdev) that can be shared with other (non-GPL) projects. Has someone told you that you couldn't possibly link an LGPL-licensed library with libuv?

digital man

Synchronet "Real Fact" #36:
Synchronet's Windows Control Panel is built with Borland C++ Builder.
Norco, CA WX: 58.8øF, 33.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Re: Source Request
By: tracker1 to Deuce on Tue Nov 17 2015 07:25 pm

Pulling that in to something else that's not based around the DOS share modes would be a mistake IMHO. Synchronet has a long history of using SHARE stuff, so it makes sense to emulate that on other OSs. This likely does NOT make sense for libuv.

Fair enough, but isn't range locking important to interoperate
with different programs (such as synchronet)? If I use node's
shared read/write access and don't do any locking, won't
things potentially mess up?

Both range locking and file locking can be necessary to interoperate with Synchronet.

In the general case, the program that "owns" the file defines the synchronization mechanism. Synchronet used file locking for some and record locking for others, and even both for some files. On a single OS (ie: DOS or Windows), this worked out fine... but the record and file locking semantics are different between Windows and *nix, so Windows semantics are emulated on *nix (since the code was written for Windows).

A further issue is that not all *nix file systems support both record and file locking, resulting in them being emulated with each other sometimes (and dotfile locking being used some other places).

Yet ANOTHER issue is that some systems support madatory locking (once it's locked, operations like write() fail) and others support advisory locking (only locks are blocked, so everyone has to call lock). Some support both as an option during the lock operation, and some support both, but only one type for a specific file system.

A particularly bad thing about *nix fcntl() locks is that if any thread in the process closes a file, ALL LOCKS held on that file are lost - even if they have a different file handle (thread1 opens "/tmp/temp" and locks the first byte, thread2 opens "/tmp/temp" and locks the second byte, thread1 closes "/tmp/temp", and thread2 no longer has the second byte locked).

The UAV issue 318 you mentioned seems to have a cross-platform locking API already, so using that should work.

Regarding the locked read/write functions mentioned in node.js issue #1426, those functions would be mostly useless... the idea is that that you lock a record to prevent anyone else from changing it for a period of time. The most common usage is if you're going to update it... you lock the record, read it, modify it, write it, then unlock it. If the lock only protects the read and the write, you can end up losing changes someone else did while you modified your copy.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

libuv isn't (L)GPL, so even looking at the source beyond
the license at the top could be considered to be tainting
the project in question.

The whole point of LGPL is to be able to create libraries (like xpdev) that can be shared with other (non-GPL) projects. Has someone told you that you couldn't possibly link an LGPL-licensed library with libuv?

They wouldn't link to xpdev... libuv serves the same purpose as xpdev does, it's
just that it doesn't have range locking in its' file system abstraction, which is a feature I'd like, so I can interact with synchronet data from node.js.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

A particularly bad thing about *nix fcntl() locks is that if any thread in the process closes a file, ALL LOCKS held on that file are lost - even if they have a different file handle (thread1 opens "/tmp/temp" and locks the first byte, thread2 opens "/tmp/temp" and locks the second byte, thread1 closes "/tmp/temp", and thread2 no longer has the second byte locked).

That sounds very problematic that locks aren't per file handle that way.
Which may negate even the use of the utility.

The UAV issue 318 you mentioned seems to have a cross-platform locking API already, so using that should work.

Will have to double-check as the library mentioned didn't have a windows implementation, not that I personally need it, but anything I write around it wouldn't be cross platform.

Regarding the locked read/write functions mentioned in node.js issue #1426, those functions would be mostly useless... the idea is that that you lock a record to prevent anyone else from changing it for a period of time. The most common usage is if you're going to update it... you lock the record, read it, modify it, write it, then unlock it. If the lock only protects

the

read and the write, you can end up losing changes someone else did while

you

modified your copy.

The third method was actually meant to be a lock, then wouldn't unlock until `done` was called, optionally with the new bytes to write to the file (Buffer object), meant to do atomic updates to a record.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/

Re: Re: Source Request
By: tracker1 to Deuce on Thu Nov 19 2015 07:26 pm

The UAV issue 318 you mentioned seems to have a cross-platform locking API already, so using that should work.

Will have to double-check as the library mentioned didn't have a windows implementation, not that I personally need it, but anything I write around it wouldn't be cross platform.

I took a quick glimpse at that code, and I'm pretty sure I saw Windows support in there. I could be mis-remembering I suppose.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Source Request
By: tracker1 to Deuce on Thu Nov 19 2015 07:26 pm

The UAV issue 318 you mentioned seems to have a cross-platform locking API already, so using that should work.

Will have to double-check as the library mentioned didn't have a windows implementation, not that I personally need it, but anything I write around it wouldn't be cross platform.

I took a quick glimpse at that code, and I'm pretty sure I saw Windows support in there. I could be mis-remembering I suppose.

It's been some time since I've looked into it... so it may have
been added since I last looked. The node community does
move very quickly...

Mental note: customize my bbs website already.
--
Michael J. Ryan
tracker1(at)gmail.com
+o Roughneck BBS

---
þ Synchronet þ RoughneckBBS - http://www.roughneckbbs.com/