This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc stacking up to Windows
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/