Re: FYI: bootstrap dangling symlink tweaks
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 4/1/2008 9:25 AM: | The first is because I found a few persistent dangling symlinks | in lib/*.[ch] to be annoying. | +find $m4_base $source_base \ | + -name '*.m4' -depth -type l -xtype l -delete /dev/null 21 Except that doesn't delete dangling links in lib/*.[ch]. You need something like: find $m4_base $source_base -depth \ ~ \( -name '*.m4' -o -name '*.[ch]' \) -type l -xtype l -delete Thanks. Here's what I'll probably use: bootstrap: remove dangling *.[ch] symlinks from lib * bootstrap [dangling symlink removal]: Match *.[ch] files, too. Suggestion from Eric Blake. diff --git a/bootstrap b/bootstrap index 94d8921..1274af2 100755 --- a/bootstrap +++ b/bootstrap @@ -549,8 +549,8 @@ if test -f $mam_template; then done fi -# Remove any dangling symlink matching *.m4 in the gnulib-populated -# $m4_base directory, since such a file would cause aclocal to fail. +# Remove any dangling symlink matching *.m4 or *.[ch] in some +# gnulib-populated directories. Such .m4 files would cause aclocal to fail. # The following requires GNU find 4.2.3 or newer. Considering the usual # portability constraints of this script, that may seem a very demanding # requirement, but it should be ok. Ignore any failure, which is fine, @@ -558,7 +558,8 @@ fi # unusual case in which a symlinked-to .m4 file is git-removed from gnulib # between successive runs of this script. find $m4_base $source_base \ - -depth -name '*.m4' -type l -xtype l -delete /dev/null 21 + -depth \( -name '*.m4' -o -name '*.[ch]' \) \ + -type l -xtype l -delete /dev/null 21 # Reconfigure, getting other files. -- 1.5.5.rc2.7.g0b2fe ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
[EMAIL PROTECTED] wrote: Bad news fellows, regarding: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. Well it just so happens that the resolution on all(?) vfat flash cards, is TWO seconds, $ w3m -dump http://en.wikipedia.org/wiki/File_Allocation_Table | grep 2\ sec Note that the seconds is recorded only to a 2 second $ cd some/directory/on/my/vfat/flash_card $ stat *|perl -nwe 'm/^Modify:.*(\d\d)\.000/print $1'; echo 04 02 02 02 24 04 04 58 00 24 16 58 58 02 34 --all TWO seconds, (so they are always even numbers above.) This means that set /non-vfat/file /vfat/file $ cp -p $1 $2 #if done during an odd-numbered second of time, $ cp -u $1 $2 #will cause this second line to wastefully fire again. So please investigate your claim that the comparison is to the source time stamp truncated to the resolutions of the destination file system I bet that you never dreamed that you had to consider more than one second vs. fractional second differences. Yes, it's unfortunate that FAT does not allow for higher resolution st_mtime, like it does for creation time. Yet another reason to avoid FAT, whenever possible. It'd be great if you would suggest wording to document this discrepancy. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 that everything created by install gets the user and group permissions when they are provided. I apologize in advance if this has previously been covered. I searched the archive before posting, but it's possible that I failed to use the right keywords. Good catch. That's a bug. Would you like to submit a patch that fixes it? If so, please look through the new contribution guidelines, just renamed to HACKING (feedback welcome): http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 for example. */ + signal (SIGQUIT, cleanup);/* Ctrl-\ at terminal for example. */ + signal (SIGTERM, cleanup);/* if we're killed, stop monitored process. */ + signal (SIGHUP, cleanup); /* terminal closed for example. */ + signal (SIGTTIN, SIG_IGN);/* don't sTop if background child needs tty. */ + signal (SIGTTOU, SIG_IGN);/* don't sTop if background child needs tty. */ if you're using signal(), you have race problems. why not use sigaction() and friends instead ? I originally wrote this for util-linux-ng. BSD and linux at least handle signal() sanely so I wrote it for those. Since coreutils needs to be more portable, I'll change to the more complicated sigaction instead. 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 there is the issue of resetting the signal handler after it has run. Are there systems that coreutils supports currently that doesn't follow BSD/linux semantics wrt the above 3 points? thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 minutes, `h' for + hours, or `d' for days. If SUFFIX_CHAR is invalid, don't modify *X + and return false. If *X would overflow, don't modify *X and return false. + Otherwise return true. */ + +static bool +apply_suffix (unsigned int *x, char suffix_char) You probably expect this, but I have to say it ;-) Don't duplicate code! apply_suffix is a tiny function, and used also by sleep.c, so let's not duplicate it. How about putting it (static inline) in system.h instead? operand2sig is similar but not as lightweight, since it uses str2sig, error, xstrdup and W* macros. Maybe put it in its own file in src/? Or change xstrdup to strdup, eliminate the error call, and consider putting it in lib/gnulib. It's probably better to go the easier route and use a separate file in src/[ch]. Rather than '???' (or in addition to), please mark such comments with FIXME. ... + /* 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 for example. */ + signal (SIGQUIT, cleanup);/* Ctrl-\ at terminal for example. */ + signal (SIGTERM, cleanup);/* if we're killed, stop monitored process. */ Mike Frysinger's point is a good one: use signal only if absolutely necessary. Prefer sigaction. Most signal-handling code in coreutils uses sigaction, and falls back on signal ifndef SA_NOCLDSTOP. But the ifdefs and code duplication are pretty ugly. If you're game, I'd like to try using *only* sigaction for an initial test release, in order to see if any reasonable portability targets remain that lack sigaction support. Then, if there are no build failure reports for a long enough period, we can remove the crufty signal-using #else blocks in a bunch of programs. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 `s' to denote seconds, `m' for minutes, `h' for + hours, or `d' for days. If SUFFIX_CHAR is invalid, don't modify *X + and return false. If *X would overflow, don't modify *X and return false. + Otherwise return true. */ + +static bool +apply_suffix (unsigned int *x, char suffix_char) You probably expect this, but I have to say it ;-) Don't duplicate code! of course. apply_suffix is a tiny function, and used also by sleep.c, so let's not duplicate it. How about putting it (static inline) in system.h instead? sleep's apply_suffic() works on floats where as timeout's work on ints. I'll see if I can merge them somewhat. Hmm I could allow float input to timeout (1.5d for example), and then round this to the nearest second later? operand2sig is similar but not as lightweight, since it uses str2sig, error, xstrdup and W* macros. Maybe put it in its own file in src/? Or change xstrdup to strdup, eliminate the error call, and consider putting it in lib/gnulib. It's probably better to go the easier route and use a separate file in src/[ch]. I intended but forgot to add the comment: /* FIXME: where will we refactor this to? */ I'll add a new src/ file so. Rather than '???' (or in addition to), please mark such comments with FIXME. righto + /* 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 for example. */ + signal (SIGQUIT, cleanup);/* Ctrl-\ at terminal for example. */ + signal (SIGTERM, cleanup);/* if we're killed, stop monitored process. */ Mike Frysinger's point is a good one: use signal only if absolutely necessary. Prefer sigaction. Most signal-handling code in coreutils uses sigaction, and falls back on signal ifndef SA_NOCLDSTOP. But the ifdefs and code duplication are pretty ugly. If you're game, I'd like to try using *only* sigaction for an initial test release, in order to see if any reasonable portability targets remain that lack sigaction support. Then, if there are no build failure reports for a long enough period, we can remove the crufty signal-using #else blocks in a bunch of programs. Ok, I'll assume that sigaction is available. thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 and could legitimately take anywhere from a minute to an hour, it's difficult to set an absolute timeout that doesn't risk chopping off the end of the stream. Then, with such a large timeout, my pipeline could stall in the first ten seconds and I wouldn't know for a long time. If, on the other hand, I could say that there shouldn't ever be thirty seconds without a buffer's worth of data coming through, then I could set the timeout very low and know soon after a blockage formed. For example: $ sort -m inputs/* | timeout --inactivity 1m program_prone_to_stalling Where timeout would open a pipe and dup2 the read end to child's STDIN_FILENO before exec'ing. If this sounds like a worthwhile extension I'd be happy to get to work on it and submit a patch once your initial version has settled in. Thanks, Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 modified with the attached
patch, and a small Perl program (below) than hangs after 10 seconds:
$ time yes | src/timeout -i 2s ./write_then_hang 10 /dev/null
real0m11.777s
user0m0.656s
sys 0m0.068s
Bo
-- Perl --
#!/usr/bin/perl -w
my $n = shift @ARGV || 10;
my $s = time;
print scalar(STDIN) while (time - $s $n);
while(1){ }
diff --git a/src/timeout.c b/src/timeout.c
index 7c15f1d..1f44c27 100644
--- a/src/timeout.c
+++ b/src/timeout.c
@@ -75,6 +75,9 @@
# define WTERMSIG(s) ((s) 0x7F)
#endif
+/* Size of atomic reads. */
+#define BUFFER_SIZE (16 * 1024)
+
static int timed_out;
static int term_signal = SIGTERM; /* same default as kill command. */
static int monitored_pid;
@@ -83,6 +86,7 @@ static char *program_name;
static struct option const long_options[] = {
{signal, required_argument, NULL, 's'},
+ {inactivity, no_argument, NULL, 'i'},
{NULL, 0, NULL, 0}
};
@@ -144,8 +148,10 @@ Mandatory arguments to long options are mandatory for short options too.\n\
-s, --signal=SIGNAL\n\
specify the signal to be sent on timeout.\n\
SIGNAL may be a name like `HUP' or a number.\n\
- See `kill -l` for a list of signals\n), stdout);
-
+ See `kill -l` for a list of signals\n\
+ -i, --inactivity\n\
+ act as a filter and only timeout if NUMBER\n\
+ seconds have passed without data flowing.\n), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
fputs (_(\n\
@@ -250,6 +256,8 @@ main (int argc, char **argv)
{
unsigned long timeout;
char signame[SIG2STR_MAX];
+ bool inactivity = false;
+ int pipefds[2];
int c;
char *ep;
@@ -265,7 +273,7 @@ main (int argc, char **argv)
parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, VERSION,
usage, AUTHORS, (char const *) NULL);
- while ((c = getopt_long (argc, argv, +s:, long_options, NULL)) != -1)
+ while ((c = getopt_long (argc, argv, +s:i, long_options, NULL)) != -1)
{
switch (c)
{
@@ -274,6 +282,9 @@ main (int argc, char **argv)
if (term_signal == -1)
usage (ECANCELED);
break;
+case 'i':
+ inactivity = true;
+ break;
default:
usage (ECANCELED);
break;
@@ -315,6 +326,12 @@ main (int argc, char **argv)
signal (SIGTTIN, SIG_IGN);/* don't sTop if background child needs tty. */
signal (SIGTTOU, SIG_IGN);/* don't sTop if background child needs tty. */
+ if (inactivity)
+{
+ if (pipe(pipefds) == -1)
+perror (pipe);
+}
+
monitored_pid = fork ();
if (monitored_pid == -1)
{
@@ -325,6 +342,13 @@ main (int argc, char **argv)
{ /* child */
int exit_status;
+ if (inactivity)
+{
+ close (pipefds[1]);
+ close (STDIN_FILENO);
+ dup2 (pipefds[0], STDIN_FILENO);
+}
+
/* exec doesn't reset SIG_IGN - SIG_DFL. */
signal (SIGTTIN, SIG_DFL);
signal (SIGTTOU, SIG_DFL);
@@ -342,6 +366,21 @@ main (int argc, char **argv)
alarm ((unsigned int) timeout);
+ if (inactivity)
+{
+ int bytes_read;
+ char buf[BUFFER_SIZE];
+ close (pipefds[0]);
+ close (STDOUT_FILENO);
+ dup2 (pipefds[1], STDOUT_FILENO);
+ while ((bytes_read = read(STDIN_FILENO, buf, BUFFER_SIZE)) 0)
+{
+ if ((write(STDOUT_FILENO, buf, bytes_read)) == -1)
+perror (write);
+ alarm ((unsigned int) timeout);
+}
+}
+
/* We're just waiting for a single process here, so wait() suffices.
* Note the signal() calls above on linux and BSD at least, essentially
* call the lower level sigaction() with the SA_RESTART flag set, which
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 long time though. Consider the following using a timeout.c modified with the attached patch, and a small Perl program (below) than hangs after 10 seconds: $ time yes | src/timeout -i 2s ./write_then_hang 10 /dev/null replacing `yes` with `while true; do yes; sleep 1; done` causes this to hang for ages. I'll have another look at this when I finalize `timeout` thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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=12064507403r=1w=2
and the debian bug tracking system: http://bugs.debian.org/472590
The problem is that on an SELinux-enabled system, 'ls -l's +,
the alternate access method indicator, is useless, because it
appears on every file:
$ ls -glo /var
total 164
drwxr-xr-x+ 3 4096 2008-03-29 08:43 kerberos
drwxr-xr-x+ 39 4096 2008-03-29 08:43 lib
drwxr-xr-x+ 2 4096 2008-03-27 17:33 local
drwxrwxr-x+ 8 4096 2008-03-31 04:15 lock
drwxr-xr-x+ 20 4096 2008-03-31 09:55 log
lrwxrwxrwx+ 1 10 2008-03-28 23:33 mail - spool/mail
...
Newer POSIX allows any non-space character as the indicator, and
that's what we're discussing now.
]
Russell Coker [EMAIL PROTECTED] wrote:
On Wednesday 26 March 2008 04:31, Michael Stone [EMAIL PROTECTED] wrote:
if (acl) then '+'
else if (selinux) then '.'
Should there be some special marking of files with both a SE Linux context
and
an ACL?
Pity that they didn't choose an a to mark an ACL which would then permit
using A for ACL + MAC.
This is probably as good a time as any to make such a change, though
I doubt it will make the cut for the upcoming release. I'd like to keep
it simple (i.e., not try to encode all possible combinations). If you
want to get full details, stat(1) is probably the program to change.
I like Michael's suggestion. Rephrasing it,
if (SELinux, with no other MAC or ACL)
use '.'
else if (any other combination of alternate access methods)
use '+'
If someone who already has a copyright assignment on file for coreutils
wants to write the patch (including doc update, tests, NEWS, ChangeLog,
etc.), please speak up ASAP. Otherwise I'll do it.
No one spoke up, so here's code, for discussion's sake.
I've tested it only lightly.
This change is not slated for the upcoming release.
Here's sample output, running on an SELinux system:
$ src/ls -ldgo [ac]*
-rw-r--r--. 1 42625 2008-04-02 19:31 aclocal.m4
drwxr-xr-x. 24096 2008-04-02 19:31 autom4te.cache
-rw-r--r--. 11597 2008-03-21 16:35 cfg.mk
-rw-r--r--. 1 1417195 2008-04-02 19:33 config.log
-rwxr-xr-x. 1 71225 2008-04-02 19:33 config.status
-rwxr-xr-x. 1 1846424 2008-04-02 19:31 configure
-rw-r--r--. 1 12014 2008-03-25 23:55 configure.ac
Use '.' (not +) as SELinux-only alternate access flag in ls -l output
* src/ls.c (gobble_file) [long_format]: Map SELinux-only to '.',
any other nonempty combination of MAC and ACL to '+', and all else
to the usual ' '.
* tests/misc/selinux: Adapt: expect '.', not '+'.
* NEWS: TBD
---
src/ls.c | 25 +++--
tests/misc/selinux |4 ++--
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/src/ls.c b/src/ls.c
index e029fe0..ae234da 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -151,6 +151,12 @@ verify (sizeof filetype_letter - 1 == arg_directory + 1);
C_LINK, C_SOCK, C_FILE, C_DIR \
}
+enum acl_type
+ {
+ACL_T_NONE,
+ACL_T_SELINUX_ONLY,
+ACL_T_YES
+ };
struct fileinfo
{
@@ -179,7 +185,7 @@ struct fileinfo
/* For long listings, true if the file has an access control list,
or an SELinux security context. */
-bool have_acl;
+enum acl_type acl_type;
};
#define LEN_STR_PAIR(s) sizeof (s) - 1, s
@@ -2671,6 +2677,7 @@ gobble_file (char const *name, enum filetype type, ino_t
inode,
if (format == long_format || print_scontext)
{
+ bool have_selinux = false;
bool have_acl = false;
int attr_len = (do_deref
? getfilecon (absolute_name, f-scontext)
@@ -2689,7 +2696,7 @@ gobble_file (char const *name, enum filetype type, ino_t
inode,
}
if (err == 0)
- have_acl = ! STREQ (unlabeled, f-scontext);
+ have_selinux = ! STREQ (unlabeled, f-scontext);
else
{
f-scontext = UNKNOWN_SECURITY_CONTEXT;
@@ -2702,15 +2709,19 @@ gobble_file (char const *name, enum filetype type,
ino_t inode,
err = 0;
}
- if (err == 0 ! have_acl format == long_format)
+ if (err == 0 format == long_format)
{
int n = file_has_acl (absolute_name, f-stat);
err = (n 0);
have_acl = (0 n);
}
- f-have_acl = have_acl;
- any_has_acl |= have_acl;
+ f-acl_type = (!have_selinux !have_acl
+? ACL_T_NONE
+: (have_selinux !have_acl
+ ? ACL_T_SELINUX_ONLY
+ : ACL_T_YES));
+ any_has_acl |= f-acl_type != ACL_T_NONE;
if (err)
error
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 if detected FAT, I suppose. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 to use two-second buckets to compare if detected FAT, I suppose. It's always simple in principle... There are two ways to address the discrepancy: - change code (probably impossible to do non-invasively and efficiently enough to satisfy me). Evidence to the contrary would be welcome, of course. - document a subtle limitation encountered when using a losing file system Guess which one I choose? ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 second bucket too The Linux guys went through all the trouble to be able to write the file into the two second bucket, and they you fellows don't follow along: ah ha: GNU/Linux becomes GNU ... / ... Linux: a crack appears. Anyways, all this to encourage you not to make your previous compliancy start to crack due to a moment of convenience. Or whatever. I'm having a vegi-burger. See ya. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 so it should be just as easy to add a two second bucket too Sorry, but as far as I know, it's not easy at all, in the context of cp. Keep this in perspective: i.e., what's the penalty for not changing the code to match the documentation? The second cp -u invocation in the right two-second interval will do some useless work. Not worth worrying about. The Linux guys went through all the trouble to be able to write the file into the two second bucket, and they you fellows don't follow along: ah ha: GNU/Linux becomes GNU ... / ... Linux: a crack appears. Don't blame Linux ;-) This is due to the FAT specification. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 future charges. JM Don't blame Linux ;-) JM This is due to the FAT specification. Different filesystems have different time granularities. Why draw an artificial line above one second just because it is unfamiliar? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
