bug report coreutuls / gnuls

2005-05-18 Thread Stea Linx
Hi, got to report this. while i was making coreutils on a netbsd 2.0.2 pc with pkgsrc i got this warning: checking sys/mount.h usability... no checking sys/mount.h presence... yes configure: WARNING: sys/mount.h: present but cannot be compiled configure: WARNING: sys/mount.h: check for

Re: mkdir when target exists and is a broken symlink

2005-05-18 Thread Paul Eggert
Avis, Ed [EMAIL PROTECTED] writes: There could be some kind of -f, --follow option so that mkdir will create the directory pointed to. There is a potential security problem there, if the symbolic link is in a directory writable by an attacker. You'd probably use it together with -p. Then

RE: mkdir when target exists and is a broken symlink

2005-05-18 Thread Avis, Ed
Eric Blake wrote: There could be some kind of -f, --follow option so that mkdir will create the directory pointed to. You'd probably use it together with -p. This sounds somewhat similar to cp -f, --force. cp uses slightly different semantics, required by POSIX (rather than try to create the

Re: mkdir when target exists and is a broken symlink

2005-05-18 Thread Eric Blake
I note that 'touch foo' when foo is a broken symlink will create the link destination if possible (though without making any directories, obviously). POSIX requires this, but it is arguably a misfeature, due to the security issues mentioned. Perhaps we should add an option to touch to

dependency fixes and old-cruft removal

2005-05-18 Thread Paul Eggert
Partly inspired by the recent fts changes, I installed the following patch to remove and fix some dependencies and old cruft. Also I added some copyright notices to modified nontrivial files that lacked them. This shouldn't affect any behavior. 2005-05-18 Paul Eggert [EMAIL PROTECTED]

Re: ls -lF dereferences symbolic links - ?bug or feature?

2005-05-18 Thread Eric J Haywiser
Paul, Thank you for your reply. Eric J Haywiser [EMAIL PROTECTED] writes: Apparently ls -lF classifies the link reference rather than the link itself, while ls -F classfies the link. On Thu, 12 May 2005, Paul Eggert wrote: Paul I don't observe this behavior with coreutils 5.3.0 ls. Paul

Re: bug in du

2005-05-18 Thread Paul Eggert
Eric Blake [EMAIL PROTECTED] writes: One possible fix is revisiting line 377 in src/du.c in CVS, which currently skips hard links only if a file has multiple links. Sorry, I don't quite follow this. Don't all the directories in question have multiple links? Or, if you're talking about