Re: new snapshot (rm fixes and new program: mktemp)
Jim Meyering wrote: Bauke Jan Douma [EMAIL PROTECTED] wrote: Never heard of it! Is this it: http://tukaani.org/lzma/ ? Yes. Is it considered mature/stable?? The compression code is stable (it's from stable LZMA SDK). Beta refers mostly to the command line tool. It never got all the features that were planned, because development switched to a new branch, which has been under development over a year now. As a result, the old 4.32.0betas branch were left to be called betas. The alpha versions have nothing stable, not even the core of the compression code. Don't trust them. They are there only for testing. The 4.32.0betas have been used by a few (small) GNU+Linux distros as part of the package management (all packages compressed with LZMA). LZMA has worked reliably in all situations that I'm aware. The command line tool has had some minor bugs (no data corruption bugs) but those have been fixed. The biggest problem is that the current .lzma format doesn't have any integrity check. If a few bits flip in the compressed file, it may go undetected especially if the flipped bits are near the end of the file. This will be fixed in the new .lzma format, but there are no stable tools to handle that format yet. -- Lasse Collin | IRC: Larhzu @ IRCnet Freenode ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
feature request: zero-terminated lines for comm
How complicated it would be to add a `-z' or `-0' switch to `comm' in order to allow zero-terminated lines? The `sort' command, for example, allows this, and this is very useful when dealing with filenames. Or is such functionality already provided in a different way? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls when acl() is busy [was: ls slow on top-level directory]
Eric Blake wrote: According to Corinna Vinschen on 6/28/2005 2:34 AM: However, IMHO, ls should be changed to just print no error message, if file_has_acl() returns -1 and errno is set to EBUSY, and the file should simply be treated as a file with no ACL. That's the least intrusive way, IMHO. Certainly less intrusive, but also potentially misleading. The point of a new character is to make it obvious that ls was unable to determine if there are ACLs, rather than that the file has no alternate access. IMO, it should be the other way around, i.e. no error but a '+' to signify an ACL, for two reasons: 1. Transperency. Since the UNIX permissions are emulated, one could argue that all files should have the '+' displayed... 2. Probability. If the file is busy there's good chance that the file has an ACL. I view the '+' as a reminder that there's more to it than what is shown and I think that would be right thing to convey for busy files. I think this behaviour would be the least surprising... -- /Lasse ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
