> > Only because someone volunteers to maintain it. > > So, if I volunteer to maintain win32 support, would coreutils accept the > changes?
If your changes are not deemed too invasive (you haven't even posted them yet), and if you have copyright assignment, then perhaps Jim will be willing to let you maintain such patches. But why not maintain them for a windows-specific port, rather than forcing those patches upstream on all platforms? > First, I tend to agree with GNU's approach here. > Second, I think there's a confusion here: Posix/unix-like API is indeed > non-proprietary, but it's *not portable* by no means; a portable API means > it abstracts away any underlying OS objects using undefined structs and > opaque void* types. No, a portable API means that it compiles on multiple platforms (namely, all platforms which implement POSIX or a reasonable subset thereof). It has nothing to do with how much or little it abstracts away OS details. > for instance (a) it assumes a user/group identifier is always a uid_t/gid_t > (integral type), (b) no support for arbitrary-file-system per-file > information, such as hidden/system attribute on win32 or file version on > VMS, hence there's no way of copying it from file to file (cp -p is hurt > here). In a portable world, you are correct - file attributes not specified by POSIX are inherently non-portable, so they cannot reasonably be expected to be managed by a portable application. Making cp -p preserve non-portable attributes is the wrong approach, instead, you should use an OS-specific application that is aware of the OS's non-portable extensions if you want those extensions preserved across copies. > (c) It assumes the underlying FS has inodes; I guess cp's hardlink > detection breaks when a linux machine mounts an NTFS. NTFS supports hardlinks and inodes just fine. Rather than guessing, why not test your claim. And if it really is broken on Linux accessing NTFS, then the bug is not in coreutils, but in the Linux NTFS file system layer. > I think a truly portable (and therefore extensible) OS API is a real need of > the GNU community. A well-designed API could make lives much easier for > everybody - users and maintainers. You are more than welcome to join the Austin group and make your proposals for new portable APIs; but good luck getting it approved without any prior implementations to back it up. And don't go expecting us to rewrite code with years of history just to use your new APIs, if you can't prove that your approach is more sound than years of industry experience. > > I don't think you're the responsible for cygwin's non-working stuff. Such > problems are inherent to cygwin as it supplies a posix API - which is not > portable, as I said above. Cp -p could never preserve hidden file attributes > using a posix emulation layer - to mention one burning example. And that's why I claim that cygwin is not broken - since hidden file attributes are outside the realm of POSIX and portability, I have no desire for cygwin's cp -p to try and preserve it. Rather, since it is an OS-specific attribute, I use OS-specific tools when I want the non-POSIX hidden attributes preserved across copies. -- Eric Blake _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils