copyright years: mass-update every January 1
Karl Berry just mentioned that it's now considered fine (recommended, even) to update all copyright lists to include the new year on January 1. Before, it was recommended not to do that, but rather to update each list only upon modifying the corresponding file in the course of development. This is documented: maintain(Copyright Notices), specifically: To update the list of year numbers, ... It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. I prefer to have one change set per year updating all copyright year lists, rather than having a copyright-list update as part of the first change of the year for files modified in the normal course of development. So I did the mass-update in coreutils. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
On Thu, 25 Jun 2009, Jim Meyering wrote: Karl Berry just mentioned that it's now considered fine (recommended, even) to update all copyright lists to include the new year on January 1. I realise this list may not be the right place for GNU policy discussion, but how will this affect the eventual migration of coreutils works into the public domain? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
Philip Rowlands wrote: On Thu, 25 Jun 2009, Jim Meyering wrote: Karl Berry just mentioned that it's now considered fine (recommended, even) to update all copyright lists to include the new year on January 1. I realise this list may not be the right place for GNU policy discussion, but how will this affect the eventual migration of coreutils works into the public domain? Hi Phil, migration of coreutils works into the public domain I know of no such plan. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
On Thu, 25 Jun 2009, Jim Meyering wrote: migration of coreutils works into the public domain I know of no such plan. I'm refering to the copyright term limits which apply to all works, not a specific plan for coreutils. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
migration of coreutils works into the public domain I know of no such plan. I'm refering to the copyright term limits which apply to all works, not a specific plan for coreutils. It doesn't affect it at all, if you use a version of coreutils from 1980, then the copyright term will be from that date. If you use a version from 2100 then it will be from that date. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inotify back end for tail -f on linux
Jim Meyering wrote:
diff --git a/NEWS b/NEWS
index d7695e4..754f9e2 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,8 @@ GNU coreutils NEWS-*-
outline -*-
sort accepts a new option, --human-numeric-sort (-h): sort numbers
while honoring human readable suffixes like KiB and MB etc.
+ tail uses inotify when possible.
+
That's a little terse. How about:
tail --follow uses inotify when possible to be more responsive
to file changes and also be more scalable when many files are monitored.
diff --git a/src/tail.c b/src/tail.c
index 9d416e1..059ee82 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1691,7 +1933,24 @@ main (int argc, char **argv)
ok = tail_file (F[i], n_units);
if (forever)
-tail_forever (F, n_files, sleep_interval);
+{
+#if HAVE_INOTIFY
+ if (pid == 0)
+{
+ int wd = inotify_init ();
+ if (wd 0)
+error (0, errno, _(inotify cannot be used, reverting to
polling));
Do we need to warn here since the fallback is functionally equivalent?
It's OK if the error is rare, but I'm worried that errors might be issued
from /sys or /proc or if the user boots an old kernel, or whatever.
Well not that worried TBH, just mentioning it :)
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inotify back end for tail -f on linux
Pádraig Brady wrote: Jim Meyering wrote: diff --git a/NEWS b/NEWS index d7695e4..754f9e2 100644 --- a/NEWS +++ b/NEWS @@ -28,6 +28,8 @@ GNU coreutils NEWS-*- outline -*- sort accepts a new option, --human-numeric-sort (-h): sort numbers while honoring human readable suffixes like KiB and MB etc. + tail uses inotify when possible. + That's a little terse. How about: tail --follow uses inotify when possible to be more responsive to file changes and also be more scalable when many files are monitored. Sure. Mentioning improved responsiveness is better. What do you mean by more scalable? It's currently still subject to the limit on number of open file descriptors, which is tied to the number of tailed files. ... + if (wd 0) +error (0, errno, _(inotify cannot be used, reverting to polling)); Do we need to warn here since the fallback is functionally equivalent? It's OK if the error is rare, but I'm worried that errors might be issued from /sys or /proc or if the user boots an old kernel, or whatever. Well not that worried TBH, just mentioning it :) If I'm using tail -f on a system that *should* support the inotify-enabled code, I want to know right away (and why, hence errno) if that fails. Otherwise, we'd have to wait for someone to notice the degraded performance and to debug it to determine why it reverted to the old method. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inotify back end for tail -f on linux
Jim Meyering wrote: Pádraig Brady wrote: Jim Meyering wrote: diff --git a/NEWS b/NEWS index d7695e4..754f9e2 100644 --- a/NEWS +++ b/NEWS @@ -28,6 +28,8 @@ GNU coreutils NEWS-*- outline -*- sort accepts a new option, --human-numeric-sort (-h): sort numbers while honoring human readable suffixes like KiB and MB etc. + tail uses inotify when possible. + That's a little terse. How about: tail --follow uses inotify when possible to be more responsive to file changes and also be more scalable when many files are monitored. Sure. Mentioning improved responsiveness is better. What do you mean by more scalable? It's currently still subject to the limit on number of open file descriptors, which is tied to the number of tailed files. Well I was thinking it would be more efficient than polling as the number of files monitored was increased. How about: tail --follow now uses inotify when possible, to be more responsive to file changes and also be more efficient when many files are monitored. + if (wd 0) +error (0, errno, _(inotify cannot be used, reverting to polling)); Do we need to warn here since the fallback is functionally equivalent? It's OK if the error is rare, but I'm worried that errors might be issued from /sys or /proc or if the user boots an old kernel, or whatever. Well not that worried TBH, just mentioning it :) If I'm using tail -f on a system that *should* support the inotify-enabled code, I want to know right away (and why, hence errno) if that fails. Otherwise, we'd have to wait for someone to notice the degraded performance and to debug it to determine why it reverted to the old method. Cool. Just ensuring it was considered. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inotify back end for tail -f on linux
Pádraig Brady wrote: ... Well I was thinking it would be more efficient than polling as the number of files monitored was increased. How about: tail --follow now uses inotify when possible, to be more responsive to file changes and also be more efficient when many files are monitored. Sounds good. s/also be// and here's a tweak to use active voice: tail --follow now uses inotify when possible, to be more responsive to file changes and more efficient when monitoring many files. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
Jim Meyering jim at meyering.net writes: I prefer to have one change set per year updating all copyright year lists, rather than having a copyright-list update as part of the first change of the year for files modified in the normal course of development. Sounds fine. So I did the mass-update in coreutils. Except I think you did too much. COPYING should probably remain verbatim from upstream (you are not changing upstream COPYING as part of including it in the coreutils VCS, so much as silencing an automake warning). And there were lots of ChangeLog files in the mix; even though they belong to coreutils, it just seems weird to see a copyright date of 2009 on a file named 'ChangeLog-2005'. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright years: mass-update every January 1
On Thu, 25 Jun 2009, Alfred M. Szmidt wrote: It doesn't affect it at all, if you use a version of coreutils from 1980, then the copyright term will be from that date. If you use a version from 2100 then it will be from that date. OK, but taken separately the files have/had dates to indicate the most recent amendment. I'm curious whether the slavish copying (to use a phrase from a relevant case) of old to new file, updating only the date, contributes sufficient originality to defend the change in public-domain date. Just trying to illustrate the point here; I don't intend to start a long thread, merely taking an interest in clarity of copyright terms/expiry in general. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cannot dereference error from chown -RH
if i create a dangling symbolic link within a tree, chown -RH top-of-tree gets me a cannot dereference error. STEPS TO REPRODUCE: cd /tmp mkdir chown-test cd chown-test ln -s poop parp cd .. chown -RH :nogroup chown-test ACTUAL OUTPUT: chown: cannot dereference `chown-test/parp': No such file or directory chown: changing group of `chown-test': Operation not permitted EXPECTED BEHAVIOR: i don't think chown should try to dereference the dangling symbolic link. looking at the source, i think affect_symlink_referent should be false. i think the code in chown.c's main() should be more like the code in chcon.c's main(), but that both should be changed to test (bit_flags FTS_PHYSICAL) rather than (bit_flags == FTS_PHYSICAL), because -H sets bit_flags to FTS_COMFOLLOW | FTS_PHYSICAL. alternatively, i could have completely misunderstood the intended behavior of -RH. but it seems to me like -H should cause only symbolic links explicitly named on the command-line to be dereferenced. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
