glibc stacking up to Windows

[Michael Lueck]

Alexander Shopov wrote:

> Nope, he does not. What you are asking is simply _never_ going to
> happen. At least - not unless you get the committers to the source
> repository of GNU libc bribed (if money does not get them to do it - you
> can try exotic sexual favors - this works sometimes).

http://www.gnu.org/software/libc/manual/html_node/File-System-Interface.html

Delete files, rename files... just don't copy files. "Oh, but it is SUPPOSE to be that way..." Yea right!

Fine, the "science" behind copying a file is much more involved than deleting and renaming them. That is up to the people writing the library to take care of for me. When I see a 
"File-System-Interface" I expect it to have an extensive list of filesystem related functions. Copy is pretty basic in that regard, thus glibc fails in my opinion.

> But then - as the software is free software - you will most probably get
> someone to make a fork of this mutated libc and things will get back to
> normal.

Yes, could fork it myself... but then how many boxes would I ever find with the custom glibc with the mission functions added in? No, either the API is in the library, or it does not exist.

> You can take a look at the sources of cp here and see how this is implemented:
> http://cvs.savannah.gnu.org/viewcvs/coreutils/src/cp.c?rev=1.220&root=coreutils&view=auto

Alas can't. The OSS/FS project this will be a contribution to is an IBM project they released under CPL which they love. CPL can not have any GPL "tainted" code in it.

> A. Learn the "C library" API. Reimplement what you lack.
>   (Do not copy-paste from the coreutils source as it is copyrighted,
> unless you understand the proper way to do it).

Basically stuck here due to the CPL vs GPL license compatibility.

> B. Use some other convenience library.
> You will have to find the one to your taste. If not - write such one.

The project has restricted adding additional library dependencies... so would have to dig through what is already imported but I expect glibc is by far the cornerstone of the imports... doubt I will 
find an import there that magically has a CopyFile() type API.

> C. Script the bloody thing.
> C sucks. Compilation sucks. Linking sucks. ;-)

Yes well, I don't think "scripting" belongs inside an interpreted language... soon it would be a patchwork quilt, not an interpreted language! ;-)

> D. Use winelib which reimplements Win32 API on GNU/Linux (and other
> systems as well). Leverage that knowledge you have on the Windows C API.
> http://www.winehq.com/site/winelib

Again, another add-on lib.

-- 
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/