I'm sorry but this is getting much too religious debate, and I don't really have the time to spend on it.
If you want the updates, I'll post them (along with additional changes to support mv & cp). If not, it's a pity - I think you're turning against your users. > -----Original Message----- > From: Eric Blake [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 15, 2007 17:46 > To: Aviad Lahav > Cc: bug-coreutils@gnu.org > Subject: RE: coreutils rm - win32 native port > > > > 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