RE: coreutils rm - win32 native port

[Eric Blake]

> > 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