RE: coreutils rm - win32 native port

[Aviad Lahav]

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:address@hidden
> Sent: Wednesday, August 15, 2007 17:46
> To: Aviad Lahav
> Cc: address@hidden
> 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