[PATCH] build: prefix a few rules with $(AM_V_GEN)

2009-08-27 Thread Jim Meyering
FYI, From de619c8fa5ea4e5cd3ca4a9632af81a487c33c0b Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 27 Aug 2009 10:17:55 +0200 Subject: [PATCH] build: prefix a few rules with $(AM_V_GEN) * Makefile.am (.version, dist-hook, gen-ChangeLog): Use $(AM_V_GEN) and $(AM_V_at),

sort -R not working

2009-08-27 Thread Barty Pleydell-Bouverie
Hi sort -R fails to randomly sort files. I am using fedora8 - any known reason for this?

Re: sort -R not working

2009-08-27 Thread Philip Rowlands
On Thu, 27 Aug 2009, Barty Pleydell-Bouverie wrote: sort -R fails to randomly sort files. I am using fedora8 - any known reason for this? Fedora 8 was declared end-of-life (i.e. unsupported) on January 7, 2009. Can you reproduce this problem either with a current Fedora release, or with

Re: sort -R not working

2009-08-27 Thread Jim Meyering
Barty Pleydell-Bouverie wrote: sort -R fails to randomly sort files. I am using fedora8 - any known reason for this? Fedora 8 is rather old. I suggest you upgrade. Please show us what command you ran, and the inputs and outputs. And what sort --version prints.

Re: sort -R not working

2009-08-27 Thread Kamil Dudka
On Thursday 27 of August 2009 12:46:51 Barty Pleydell-Bouverie wrote: Hi sort -R fails to randomly sort files. I am using fedora8 - any known reason for this? Please define not working. What is the command you have used? What is the output? What is the expected output? Fedora 8 is EOL

Re: sort -R not working

2009-08-27 Thread Pádraig Brady
Barty Pleydell-Bouverie wrote: Hi sort -R fails to randomly sort files. I am using fedora8 - any known reason for this? I vaguely remember there being a bug where sort -R was not working on some locales, but the git history is not helping me out. Can you retry with `LANG=C sort -R`. I

Re: [PATCH] open: introduce O_NOSTD

2009-08-27 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Davide Libenzi on 8/25/2009 3:53 PM: Another solution is for the application to sanitize all newly-created fds: GNU coreutils provides a wrapper open_safer, which does nothing extra in the common case that open() returned 3 or larger,

Re: [PATCH] open: introduce O_NOSTD

2009-08-27 Thread Ulrich Drepper
On 08/27/2009 06:54 AM, Eric Blake wrote: I hope that my example shows why doing it in the kernel is desirable - there is no safe way to keep the pre-O_CLOEXEC efficiency using just the library, but there IS a way to do it with kernel support: You're describing a very special case where the

Re: [PATCH] open: introduce O_NOSTD

2009-08-27 Thread Florian Weimer
* Eric Blake: int open_safer (const char *name, int flags, int mode) { int fd = open (name, flags | O_CLOEXEC, mode); if (0 = fd fd = 2) { int dup = fcntl (fd, ((flags O_CLOEXEC) ? F_DUPFD_CLOEXEC : F_DUPFD), 3); int saved_errno = errno;

du counting files in hard-linked directories twice

2009-08-27 Thread Michael Schwarz
Hello everybody The Problem I see as a bug is that, in some circumstances, du is counting the same files multiple times when they appear inside of hard- linked directories. I have tested this with GNU coreutils 7.4 (MacPorts) and 7.5 (vanilla) on Mac OS X 10.5.8 on x86-64. I did all tests

Re: Correct semantics in rm -rf ?

2009-08-27 Thread shailesh jain
Here it is. Outcome is that Child gets deleted but parent does not get deleted. (Now you will say it's a filesystem issue ;) ) fstatat64(AT_FDCWD, parent, {st_mode=S_IFDIR|0755, st_size=72, ...}, AT_SYMLINK_NOFOLLOW) = 0 unlinkat(AT_FDCWD, parent, 0) = -1 EISDIR (Is a directory)

Re: Correct semantics in rm -rf ?

2009-08-27 Thread Jim Meyering
shailesh jain wrote: Here it is. Outcome is that Child gets deleted but parent does not get deleted. (Now you will say it's a filesystem issue ;) ) Let's start with the command you used here. It must not have been rm -rf, because the ENOENT is not being ignored: fstatat64(AT_FDCWD,

Re: Correct semantics in rm -rf ?

2009-08-27 Thread shailesh jain
On Thu, Aug 27, 2009 at 12:40 PM, Jim Meyering j...@meyering.net wrote: shailesh jain wrote: Here it is. Outcome is that Child gets deleted but parent does not get deleted. (Now you will say it's a filesystem issue ;) ) Let's start with the command you used here. It must not have

Re: du counting files in hard-linked directories twice

2009-08-27 Thread Matthew Woehlke
Michael Schwarz wrote: The Problem I see as a bug is that, in some circumstances, du is counting the same files multiple times when they appear inside of hard-linked directories. Hard-linked *directories*? I wasn't aware those were allowed... (If I read 'man 3 link' right, they aren't

Re: [PATCH] open: introduce O_NOSTD

2009-08-27 Thread Davide Libenzi
On Thu, 27 Aug 2009, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Davide Libenzi on 8/25/2009 3:53 PM: Another solution is for the application to sanitize all newly-created fds: GNU coreutils provides a wrapper open_safer, which does nothing extra in the

Re: [PATCH] open: introduce O_NOSTD

2009-08-27 Thread Ulrich Drepper
On Thu, Aug 27, 2009 at 15:55, Davide Libenzidavi...@xmailserver.org wrote: Can't the handling be done on close(), like (modulo some errno save/restore): No. You can have any file descriptor closed when the process is started. No close in the process with the special close.

Re: du counting files in hard-linked directories twice

2009-08-27 Thread Michael Schwarz
Am 2009-08-28 um 01:09 schrieb Matthew Woehlke: Hard-linked *directories*? I wasn't aware those were allowed... (If I read 'man 3 link' right, they aren't allowed on Linux.) That got added in Mac OS X 10.5. It allows Time Machine create a backup in O(number of changed files) time instead

Re: du counting files in hard-linked directories twice

2009-08-27 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 8/27/2009 5:09 PM: Hard-linked *directories*? I wasn't aware those were allowed... (If I read 'man 3 link' right, they aren't allowed on Linux.) POSIX permits, but does not require, them (and Linux intentionally does