Re: tail -f: --pid *and* inotify
Giuseppe Scrivano wrote:
Jim Meyering j...@meyering.net writes:
A couple of points:
Please move these declarations down into the scope where they are used.
It would be better not to perform the kill test after every
single select call when actively tailing files.
Considering how --pid is documented (in the texinfo manual),
it should be ok to call kill only when select times out (returns 0).
Of course, that means a constantly-running tail -f will
never check for process death, but that is consistent
with the documentation.
Thanks for the advises. I cleaned it following them.
I was checking for the pid every time exactly to avoid the problem that
it is never checked and can run indefinitely even if the process is
already not running.
Maybe we can add a real clock controlling how much time passed since
last check or even simpler, a counter like don't exit without check
more than N consecutive times. What do you think?
Thanks.
I've pushed it with this change to avoid a warning about the
PID parameter shadowing the global. It's best always to enable
all warnings, if you can:
./configure --enable-gcc-warnings
then such warnings are promoted to errors and stop the build.
diff --git a/src/tail.c b/src/tail.c
index 1474b06..a73ffa2 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1164,7 +1164,7 @@ wd_comparator (const void *e1, const void *e2)
Check modifications using the inotify events system. */
static void
-tail_forever_inotify (int wd, struct File_spec *f, size_t n_files, int pid,
+tail_forever_inotify (int wd, struct File_spec *f, size_t n_files,
double sleep_interval)
{
size_t i;
@@ -1256,7 +1256,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t
n_files, int pid,
struct inotify_event *ev;
- /* If a process is watched be sure that read from wd will not block
+ /* When watching a PID, ensure that a read from WD will not block
indefinetely. */
if (pid)
{
@@ -1278,7 +1278,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t
n_files, int pid,
if (n_descriptors == 0)
{
- /* Check if the process we are monitoring is still alive. */
+ /* See if the process we are monitoring is still alive. */
if (kill (pid, 0) != 0 errno != EPERM)
break;
@@ -1978,7 +1978,7 @@ main (int argc, char **argv)
error (0, errno, _(inotify cannot be used, reverting to polling));
else
{
- tail_forever_inotify (wd, F, n_files, pid, sleep_interval);
+ tail_forever_inotify (wd, F, n_files, sleep_interval);
/* The only way the above returns is upon failure. */
exit (EXIT_FAILURE);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BTRFS file clone support for cp
Andreas Schwab wrote:
Jim Meyering j...@meyering.net writes:
+#ifdef __linux__
+# define BTRFS_IOC_CLONE 1074041865
This is wrong, the actual value is architecture dependent. You should
use the _IOW macro instead.
Good point. Thanks!
I've adjusted it.
Here's the patch I'm considering now:
From 6ae1f09da25f6600f32dc540551a9479dd2e618e Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano gscriv...@gnu.org
Date: Sat, 25 Jul 2009 16:35:27 +0200
Subject: [PATCH] cp: support btrfs' copy-on-write file clone operation
* src/copy.c [HAVE_SYS_IOCTL_H]: Include sys/ioctl.h.
(BTRFS_IOCTL_MAGIC, BTRFS_IOC_CLONE): Define.
(clone_file): New function.
(copy_reg): Use the btrfs clone operation if possible.
---
src/copy.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/src/copy.c b/src/copy.c
index 4c8c432..ce4c67a 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -61,6 +61,10 @@
# include verror.h
#endif
+#if HAVE_SYS_IOCTL_H
+# include sys/ioctl.h
+#endif
+
#ifndef HAVE_FCHOWN
# define HAVE_FCHOWN false
# define fchown(fd, uid, gid) (-1)
@@ -114,6 +118,23 @@ static bool owner_failure_ok (struct cp_options const *x);
static char const *top_level_src_name;
static char const *top_level_dst_name;
+/* Perform the O(1) btrfs clone operation, if possible.
+ Upon success, return 0. Otherwise, return -1 and set errno. */
+static inline int
+clone_file (int dest_fd, int src_fd)
+{
+#ifdef __linux__
+# undef BTRFS_IOCTL_MAGIC
+# define BTRFS_IOCTL_MAGIC 0x94
+# undef BTRFS_IOC_CLONE
+# define BTRFS_IOC_CLONE _IOW (BTRFS_IOCTL_MAGIC, 9, int)
+ return ioctl (dest_fd, BTRFS_IOC_CLONE, src_fd);
+#else
+ errno = ENOTSUP;
+ return -1;
+#endif
+}
+
/* FIXME: describe */
/* FIXME: rewrite this to use a hash table so we avoid the quadratic
performance hit that's probably noticeable only on trees deeper
@@ -444,6 +465,7 @@ copy_reg (char const *src_name, char const *dst_name,
struct stat sb;
struct stat src_open_sb;
bool return_val = true;
+ bool copied = false;
source_desc = open (src_name,
(O_RDONLY | O_BINARY
@@ -589,6 +611,14 @@ copy_reg (char const *src_name, char const *dst_name,
goto close_src_and_dst_desc;
}
+ /* If --sparse=auto is in effect, attempt a btrfs clone operation.
+ If the operation is not supported or it fails then copy the file
+ in the usual way. */
+ if (x-sparse_mode == SPARSE_AUTO
+ clone_file (dest_desc, source_desc) == 0)
+copied = true;
+
+ if (!copied)
{
typedef uintptr_t word;
off_t n_read_total = 0;
--
1.6.2.5
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BTRFS file clone support for cp
Hi Pádraig, Pádraig Brady p...@draigbrady.com writes: How different exactly? OK I tried this myself on F11 with inconclusive results. I can't replicate it now, all tests I am doing report that blocks used before and after the clone are the same. Probably yesterday the difference I noticed was in reality the original file flushed to the disk. The above suggests that the clone does actually allocate space but btrfs isn't reporting it through statvfs correctly? The same message appeared here too some days ago, though I cloned only few Kb files, not much to fill the entire partition. If the clone does allocate space, then how can one clone without allocation which could be very useful for snapshotting for example? I don't know if snapshotting is handled in the same way as a clone, but in this case it seems more obvious to me that no additional space should be reported. Also I tried the above twice and both times got: http://www.kerneloops.org/submitresult.php?number=578993 I didn't get these errors. I am using the btrfs git version. Regards, Giuseppe ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug report for date
Hi, Gives me correct date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date Wed Jul 22 12:27:15 EDT 2009 Gives me incorrect date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date Tue Jul 28 18:27:09 GMT 2009 Basically I cannot go back more than 6 days... Best, Paul ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: table of contents of manual contains mistake
Pádraig Brady wrote: Benno Schulenberg wrote: Hi, Instead of showing the six system-context commands under section 21 (http://www.gnu.org/software/coreutils/manual/html_node/index.html#toc_System-context) they are shown under section 22 (SELinux context) and in a slightly different order. Maybe a newer makeinfo is needed? I still see the same issue under makeinfo 4.13. I've reordered things in the attached patch. I've just pushed: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=8aeda9b cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug report for date
Paul Grinberg wrote: Gives me correct date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date Wed Jul 22 12:27:15 EDT 2009 Gives me incorrect date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date Tue Jul 28 18:27:09 GMT 2009 Basically I cannot go back more than 6 days... You have specified an invalid timezone. Timezones are only defined from 0 through 23 hours 59 seconds which is sufficient to define all existing timezones. Please see the GNU C manual for a complete specification of the timezone using the TZ variable. http://www.gnu.org/software/coreutils/manual/libc.html#TZ-Variable The offset specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [+|-]hh[:mm[:ss]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east. The hour must be between 0 and 23, and the minute and seconds between 0 and 59. If you are trying to do math calculations using date then it is better to use date's relative time feature. $ date -R --date=-14 days Tue, 14 Jul 2009 17:04:43 -0600 Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug report for date
On Tue, 28 Jul 2009, Paul Grinberg wrote: Gives me correct date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date Wed Jul 22 12:27:15 EDT 2009 Gives me incorrect date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date Tue Jul 28 18:27:09 GMT 2009 Basically I cannot go back more than 6 days... According to the POSIX/glibc definition of TZ: http://www.opengroup.org/onlinepubs/95399/basedefs/xbd_chap08.html http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html the hour offset must be between 0 and 24. In other words, the examples above are undefined by the standards. Why are you trying to use TZ to concoct multi-day offsets? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug report for date
On Tue, 28 Jul 2009, Paul Grinberg wrote: Shell script for SolarisIt can go future as long as I want, but past only 6 days http://www.isrcomputing.com/index.php?option=com_contentview=articleid=125:unix-shell-script-to-calculate-date-in-the-future-and-in-the-pastcatid=38:technology-tipsItemid=82 That script is using (/abusing) TZ beyond its stated purpose. As Bob suggests, GNU date can perform date calculations with relative offsets, e.g. $ date -d 'now + 12 days' Mon Aug 10 00:55:32 BST 2009 Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug report for date
Bob, Thank you for your reply. You are right, I am trying to calculate time backwardsit only allows 6 days back...i need 7 :) the whole week :) Unfortunately in solaris it does not work :((( # date -R --date=-14 days date: illegal option -- R date: illegal option -- date=-14 days usage: date [-u] mmddHHMM[[cc]yy][.SS] date [-u] [+format] date -a [-]sss[.fff] Thanks, Paul -Original Message- From: Bob Proulx [mailto:b...@proulx.com] Sent: Tuesday, July 28, 2009 7:08 PM To: Paul Grinberg Cc: bug-coreutils@gnu.org Subject: Re: Bug report for date Paul Grinberg wrote: Gives me correct date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date Wed Jul 22 12:27:15 EDT 2009 Gives me incorrect date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date Tue Jul 28 18:27:09 GMT 2009 Basically I cannot go back more than 6 days... You have specified an invalid timezone. Timezones are only defined from 0 through 23 hours 59 seconds which is sufficient to define all existing timezones. Please see the GNU C manual for a complete specification of the timezone using the TZ variable. http://www.gnu.org/software/coreutils/manual/libc.html#TZ-Variable The offset specifies the time value you must add to the local time to get a Coordinated Universal Time value. It has syntax like [+|-]hh[:mm[:ss]]. This is positive if the local time zone is west of the Prime Meridian and negative if it is east. The hour must be between 0 and 23, and the minute and seconds between 0 and 59. If you are trying to do math calculations using date then it is better to use date's relative time feature. $ date -R --date=-14 days Tue, 14 Jul 2009 17:04:43 -0600 Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug report for date
Shell script for SolarisIt can go future as long as I want, but past only 6 days http://www.isrcomputing.com/index.php?option=com_contentview=articleid =125:unix-shell-script-to-calculate-date-in-the-future-and-in-the-pastc atid=38:technology-tipsItemid=82 Best, Paul -Original Message- From: Philip Rowlands [mailto:p...@doc.ic.ac.uk] Sent: Tuesday, July 28, 2009 7:40 PM To: Paul Grinberg Cc: bug-coreutils@gnu.org Subject: Re: Bug report for date On Tue, 28 Jul 2009, Paul Grinberg wrote: Gives me correct date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date Wed Jul 22 12:27:15 EDT 2009 Gives me incorrect date: [ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date Tue Jul 28 18:27:09 GMT 2009 Basically I cannot go back more than 6 days... According to the POSIX/glibc definition of TZ: http://www.opengroup.org/onlinepubs/95399/basedefs/xbd_chap08.html http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html the hour offset must be between 0 and 24. In other words, the examples above are undefined by the standards. Why are you trying to use TZ to concoct multi-day offsets? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug report for date
Phil, As I said...it is a workaround, since ins Solaris you cannot execute that command: # date -R --date=-14 days date: illegal option -- R date: illegal option -- date=-14 days usage: date [-u] mmddHHMM[[cc]yy][.SS] date [-u] [+format] date -a [-]sss[.fff] Best, Paul -Original Message- From: Philip Rowlands [mailto:p...@doc.ic.ac.uk] Sent: Tuesday, July 28, 2009 7:56 PM To: Paul Grinberg Cc: bug-coreutils@gnu.org Subject: RE: Bug report for date On Tue, 28 Jul 2009, Paul Grinberg wrote: Shell script for SolarisIt can go future as long as I want, but past only 6 days http://www.isrcomputing.com/index.php?option=com_contentview=articleid =125:unix-shell-script-to-calculate-date-in-the-future-and-in-the-pastc atid=38:technology-tipsItemid=82 That script is using (/abusing) TZ beyond its stated purpose. As Bob suggests, GNU date can perform date calculations with relative offsets, e.g. $ date -d 'now + 12 days' Mon Aug 10 00:55:32 BST 2009 Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug report for date
Paul Grinberg wrote: Thank you for your reply. You are right, I am trying to calculate time backwardsit only allows 6 days back...i need 7 :) the whole week :) Unfortunately in solaris it does not work :((( Well, this is the mailing list for the GNU system's date and so you wouldn't expect us to suggest anything other than that perhaps you might consider switching to the GNU system. It works there! :-) # date -R --date=-14 days date: illegal option -- R date: illegal option -- date=-14 days usage: date [-u] mmddHHMM[[cc]yy][.SS] date [-u] [+format] date -a [-]sss[.fff] Well, that isn't the GNU date so there isn't anything that we can say here that will help you there. Good luck! Do you have Perl, Python or Ruby? You might try doing date calculations using Perl and the Date::Calc library. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: Bug report for date
Perl is my friend :))) Best, Paul -Original Message- From: Bob Proulx [mailto:b...@proulx.com] Sent: Tuesday, July 28, 2009 8:29 PM To: Paul Grinberg Cc: bug-coreutils@gnu.org Subject: Re: Bug report for date Paul Grinberg wrote: Thank you for your reply. You are right, I am trying to calculate time backwardsit only allows 6 days back...i need 7 :) the whole week :) Unfortunately in solaris it does not work :((( Well, this is the mailing list for the GNU system's date and so you wouldn't expect us to suggest anything other than that perhaps you might consider switching to the GNU system. It works there! :-) # date -R --date=-14 days date: illegal option -- R date: illegal option -- date=-14 days usage: date [-u] mmddHHMM[[cc]yy][.SS] date [-u] [+format] date -a [-]sss[.fff] Well, that isn't the GNU date so there isn't anything that we can say here that will help you there. Good luck! Do you have Perl, Python or Ruby? You might try doing date calculations using Perl and the Date::Calc library. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
