Re: cp -u vs. vfat's TWO seconds

All I know is your program is guilty of conspiracy to wear out people's USB flash cards. If FAT is detected, just run source and destination times thru a chopper like $ m=$(date +%s); echo -n $m--\>; expr $m / 2 \* 2 1207175575-->1207175574 and cp -u will never blow it again, innocent of any futur

Re: cp -u vs. vfat's TWO seconds

[EMAIL PROTECTED] wrote: > JM> - document a subtle limitation encountered when using a losing file > system > It's the Lingua Franca of USB filesystem where I live. > > You change your comparison from > Modify: 2008-04-03 05:45:22.7 > to one second buckets > Modify: 2008-04-03 05:45:22

Re: cp -u vs. vfat's TWO seconds

JM> - document a subtle limitation encountered when using a losing file system It's the Lingua Franca of USB filesystem where I live. You change your comparison from Modify: 2008-04-03 05:45:22.7 to one second buckets Modify: 2008-04-03 05:45:22 so it should be just as easy to add a two

Re: cp -u vs. vfat's TWO seconds

[EMAIL PROTECTED] wrote: > JM> It'd be great if you would suggest wording to document this discrepancy. > > The wording is fine as is. > The problem is that you don't act according to your wording. > > You think "truncate fractional seconds, using one-second buckets to compare", > whereas you need

Re: cp -u vs. vfat's TWO seconds

JM> It'd be great if you would suggest wording to document this discrepancy. The wording is fine as is. The problem is that you don't act according to your wording. You think "truncate fractional seconds, using one-second buckets to compare", whereas you need to use two-second buckets to compare

RFC: changing the "+" in ls -l output to be "." or "+"

I wrote this: > [ I'm Cc'ing [EMAIL PROTECTED] > FYI, this is a continuation of discussion from the SELinux list: > http://marc.info/?t=12064507403&r=1&w=2 > and the debian bug tracking system: http://bugs.debian.org/472590 > > The problem is that on an SELinux-enabled system, 'ls -l's

Re: cp -af & special files

Michael Stone <[EMAIL PROTECTED]> wrote: > did you see this? No. > http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00018.html Otherwise I would have fixed it. I've just pushed the following: Thanks! "touch E; mkfifo F; cp -fR F E" no longer fails due to existing E *

Re: [PATCH] Add timeout utility

Bo Borgerson wrote: > On Wed, Apr 2, 2008 at 10:20 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote: >> It will always go through though as the kernel will buffer it. > > Yes, that introduces some fuzz, but I think the principle remains > viable -- the kernel will only buffer so much. That could be a

Re: [PATCH] Add timeout utility

Mike Frysinger wrote: > On Wednesday 02 April 2008, Pádraig Brady wrote: >> To be sure, are you referring to races where a signal >> can be received while in the signal handler on some systems? >> >> Also there is the issue of restarting system calls >> after the signal handler has run. >> >> Also

Re: [PATCH] Add timeout utility

On Wed, Apr 2, 2008 at 10:20 AM, Pádraig Brady <[EMAIL PROTECTED]> wrote: > It will always go through though as the kernel will buffer it. Yes, that introduces some fuzz, but I think the principle remains viable -- the kernel will only buffer so much. Consider the following using a timeout.c mod

Re: [PATCH] Add timeout utility

On Wednesday 02 April 2008, Pádraig Brady wrote: > Mike Frysinger wrote: > > On Tuesday 01 April 2008, Pádraig Brady wrote: > >> + /* Setup handlers before fork() so that we > >> + * handle any signals caused by child, without races. */ > >> + signal (SIGALRM, cleanup);/* our timeout. */

Re: [PATCH] Add timeout utility

Bo Borgerson wrote: > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Subject: [PATCH] Add new program: timeout > > Great idea for a tool! Not my idea TBH: http://mail.linux.ie/pipermail/ilug/2006-November/thread.html#90654 > Have you considered an alternate run-mode where it could operate as a > fi

Re: [PATCH] Add timeout utility

Pádraig Brady <[EMAIL PROTECTED]> wrote: > Subject: [PATCH] Add new program: timeout Great idea for a tool! Have you considered an alternate run-mode where it could operate as a filter and timeout on 'inactivity' of the pipeline? If, for instance, I have a pipeline that processes a lot of data a

Re: [PATCH] Add timeout utility

Jim Meyering wrote: > Thanks! > > Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Subject: [PATCH] Add new program: timeout > ... >> +/* Given an integer value *X, and a suffix character, SUFFIX_CHAR, >> + scale *X by the multiplier implied by SUFFIX_CHAR. SUFFIX_CHAR may >> + be the NUL byte or

Re: [PATCH] Add timeout utility

Thanks! Pádraig Brady <[EMAIL PROTECTED]> wrote: > Subject: [PATCH] Add new program: timeout ... > +/* Given an integer value *X, and a suffix character, SUFFIX_CHAR, > + scale *X by the multiplier implied by SUFFIX_CHAR. SUFFIX_CHAR may > + be the NUL byte or `s' to denote seconds, `m' for m

Re: [PATCH] Add timeout utility

Mike Frysinger wrote: > On Tuesday 01 April 2008, Pádraig Brady wrote: >> + /* Setup handlers before fork() so that we >> + * handle any signals caused by child, without races. */ >> + signal (SIGALRM, cleanup);/* our timeout. */ >> + signal (SIGINT, cleanup); /* Ctrl-C at terminal f

Re: install when used with -D, -o, and -g

Evan Dandrea <[EMAIL PROTECTED]> wrote: > When install is run with -D, -o, and -g, the directories created are > owned by the user who spawned install, rather than the user specified in > -o. Is this expected behavior? In my humble opinion, its reasonable to > assume the intention of the user is