Re: touch and utimens troubles on new/old software combinations

[Andreas Schwab]

Eric Blake <[EMAIL PROTECTED]> writes:

> I could also work on a patch like this - basically, gnulib/m4/utimens.m4
> could check whether futimens/utimensat fail with ENOSYS, and if so, treat
> them as though they were not declared.  But then you lose the ability to
> adjust timestamps to the nanosecond if you later upgrade your kernel but
> use the existing coreutils build; you would have to reconfigure and
> rebuild coreutils.  So which approach is more desirable?

You would also lose the capability to build on a system with an old
kernel, but new glibc (eg in a chroot), and getting the same result as
if building on the target system.  Runtime configure checks should be
avoided as much as possible, especially if they depend on the kernel
(the only part you cannot replace in a chroot).

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: cp doc bug

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> "cp --help" says
>
>   --preserve[=ATTR_LIST]   preserve the specified attributes (default:
>  mode,ownership,timestamps), if possible
>  additional attributes: context, links, all
>
> but the info formatted documentation does not mention 'context' and does not
> explain what 'context' means.

That is most definitely a bug, and I'm partly at fault.
As you probably know it's the SELinux context,
and the definitions for concepts and terms are lacking.
I'm hoping to be able to point to other documentation
for the majority of that.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: cp -p and metadata

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> This blog
>   
> http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and-cloning-tools-under-mac-os-x/
> has an explanation of all the kinds of file metadata that exists on MacOS X:
> resource forks, creation date, ACLs, extended attributes.
>
> Some of these (ACLs, extended attributes) also exist on Linux.
>
> Should "cp -p --preserve=all" copy these metadata?

That is a worthy goal of any program that professes to copy.

> Should --preserve have a possible value indicating extended attributes?

I suppose that depends on how useful and/or generally applicable such an
option would be.  Considering the small number of reports of cp failing
to copy this type of attribute, I have not been inclined to work on it.

But as usual, if fixing/extending this scratches your itch, and the
patches are clean and maintainable, I'll probably go for it.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: rebased timeout patch

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 6/3/2008 12:12 AM:
|
| * src/nice.c (program_name): Remove "const" in this one case,
| to avoid the warning it introduced.

Couldn't we instead use argv[0] instead of program_name in that instance,
since it is still in scope and has the correct type?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhFMFkACgkQ84KuGfSFAYD3RwCg15bgNCBBTNgK9udMSMAXGGwY
UXYAoLzQ55NTQatdwr9Pss0rrmSlfL2v
=HTjx
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: touch and utimens troubles on new/old software combinations

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Andreas Schwab on 6/3/2008 2:00 AM:
|
| You would also lose the capability to build on a system with an old
| kernel, but new glibc (eg in a chroot), and getting the same result as
| if building on the target system.  Runtime configure checks should be
| avoided as much as possible, especially if they depend on the kernel
| (the only part you cannot replace in a chroot).

Convincing argument.  I've checked in my patch, so that gnulib now uses a
runtime fallback when utimensat fails with ENOSYS.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhFMywACgkQ84KuGfSFAYAvQgCfVuPVGdTqpUHrCSN3Si+Tqyph
+d0An2BkM4MxIxiTX2e0xcntI9pTi1Vm
=K/xB
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: rebased timeout patch

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:

> According to Jim Meyering on 6/3/2008 12:12 AM:
> |
> | * src/nice.c (program_name): Remove "const" in this one case,
> | to avoid the warning it introduced.
>
> Couldn't we instead use argv[0] instead of program_name in that instance,
> since it is still in scope and has the correct type?

Good point.
And argv is already being used in the vicinity, so that's
better all around.

Thanks.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: cp and SELinux context

[Bruno Haible]

Jim Meyering wrote:
> >   --preserve[=ATTR_LIST]   preserve the specified attributes (default:
> >  mode,ownership,timestamps), if possible
> >  additional attributes: context, links, all
>
> ... it's the SELinux context,

Why does the default list of preserved attributes (mode,ownership,timestamps)
not include the SELinux context?

The SELinux FAQ [1] states that
  "When backing up and recovering files with a SELinux system, care must be
   taken to preserve SELinux context information."

Naïvely, I would think this rule should also hold when copying file trees
as root using "cp -p"?

Bruno


[1] http://www.crypt.gen.nz/selinux/faq.html#GA.10


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[patch #6532] tail -u -- unbuffered output

[Juergen Weigert]

URL:
  

 Summary: tail -u -- unbuffered output
 Project: GNU Core Utilities
Submitted by: jnweiger
Submitted on: Tuesday 06/03/2008 at 15:14
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

when tail's stdout is not a terminal, stdio library fools us by buffering
large chunks of data.
This patch adds an option to run in unbuffered mode, 
Implemented as straightforward use of fflush().




___

File Attachments:


---
Date: Tuesday 06/03/2008 at 15:14  Name: tail-unbuffered.diff  Size: 3kB  
By: jnweiger
patch against coreutils-6.11 as found in SUSE Linux 11.0


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [patch #6532] tail -u -- unbuffered output

[Jim Meyering]

Juergen Weigert <[EMAIL PROTECTED]> wrote:
> when tail's stdout is not a terminal, stdio library fools us by buffering
> large chunks of data.
> This patch adds an option to run in unbuffered mode,
> Implemented as straightforward use of fflush().
>
> Date: Tuesday 06/03/2008 at 15:14  Name: tail-unbuffered.diff  Size: 3kB
> By: jnweiger
> patch against coreutils-6.11 as found in SUSE Linux 11.0
> 

Hi Juergen,

Thank you for the patch!
Please follow the guidelines in HACKING when sending future patches:

  coreutils' contribution/style guidelines
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD


Here's a revised version of the patch (written by you?).
Changes include:
  - omit the short-name -u option
  - AFAICS, --unbuffered is useful only with --follow, so...
  - warn if --unbuffered is used without --follow
  - don't initialize "unbuffered" in main
  - report fflush failure on the spot
  - improve fwrite test (not related to your change -- just in the vicinity)

Items remaining:
  - a NEWS entry
  - texinfo documentation patch describing the option
  and saying how and when it is useful
  - a complete ChangeLog-style log entry
  - a test

None of that is a big deal, but it adds up if I take
time to do it for every patch that's accepted.

If you'd like to finish up, that'd be great.

>From 866896ce6be3b5d18b45b607a932549f4576fdf0 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 3 Jun 2008 17:51:21 +0200
Subject: [PATCH] tail: new option: --unbuffered

* src/tail.c (usage): FIXME
---
 src/tail.c |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/src/tail.c b/src/tail.c
index 1ce207e..2ba2b0a 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -144,6 +144,10 @@ static bool forever;
 /* If true, count from start of file instead of end.  */
 static bool from_start;

+/* If true, call fflush after each frwite to stdout.
+   Enabled only when used with --follow (-f).  */
+static bool unbuffered;
+
 /* If true, print filename headers.  */
 static bool print_headers;

@@ -182,7 +186,8 @@ enum
   MAX_UNCHANGED_STATS_OPTION,
   PID_OPTION,
   PRESUME_INPUT_PIPE_OPTION,
-  LONG_FOLLOW_OPTION
+  LONG_FOLLOW_OPTION,
+  UNBUFFERED_OPTION
 };

 static struct option const long_options[] =
@@ -198,6 +203,7 @@ static struct option const long_options[] =
   {"retry", no_argument, NULL, RETRY_OPTION},
   {"silent", no_argument, NULL, 'q'},
   {"sleep-interval", required_argument, NULL, 's'},
+  {"unbuffered", no_argument, NULL, UNBUFFERED_OPTION},
   {"verbose", no_argument, NULL, 'v'},
   {GETOPT_HELP_OPTION_DECL},
   {GETOPT_VERSION_OPTION_DECL},
@@ -256,7 +262,8 @@ Mandatory arguments to long options are mandatory for short 
options too.\n\
   --pid=PIDwith -f, terminate after process ID, PID dies\n\
   -q, --quiet, --silentnever output headers giving file names\n\
   -s, --sleep-interval=S   with -f, sleep for approximately S seconds\n\
-   (default 1.0) between iterations.\n\
+   (default 1.0) between iterations\n\
+  --unbuffered with -f, do not buffer output\n\
   -v, --verbosealways output headers giving file names\n\
 "), stdout);
  fputs (HELP_OPTION_DESCRIPTION, stdout);
@@ -303,7 +310,11 @@ pretty_name (struct File_spec const *f)
 static void
 xwrite_stdout (char const *buffer, size_t n_bytes)
 {
-  if (n_bytes > 0 && fwrite (buffer, 1, n_bytes, stdout) == 0)
+  if (n_bytes == 0)
+return;
+
+  if (fwrite (buffer, n_bytes, 1, stdout) != 1
+  || (unbuffered && fflush (stdout) != 0))
 error (EXIT_FAILURE, errno, _("write error"));
 }

@@ -1544,6 +1555,10 @@ parse_options (int argc, char **argv,
  }
  break;

+   case UNBUFFERED_OPTION:
+ unbuffered = true;
+ break;
+
case 'v':
  *header_mode = always;
  break;
@@ -1573,6 +1588,12 @@ parse_options (int argc, char **argv,
   error (0, 0, _("warning: --pid=PID is not supported on this system"));
   pid = 0;
 }
+
+  if (unbuffered && !forever)
+{
+  error (0, 0, _("warning: --unbuffered is useful only when following"));
+  unbuffered = false;
+}
 }

 int
--
1.5.6.rc1.2.g5648b


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: cp and SELinux context

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:

> Jim Meyering wrote:
>> >   --preserve[=ATTR_LIST]   preserve the specified attributes (default:
>> >  mode,ownership,timestamps), if possible
>> >  additional attributes: context, links, all
>>
>> ... it's the SELinux context,
>
> Why does the default list of preserved attributes (mode,ownership,timestamps)
> not include the SELinux context?
>
> The SELinux FAQ [1] states that
>   "When backing up and recovering files with a SELinux system, care must be
>taken to preserve SELinux context information."
>
> Naïvely, I would think this rule should also hold when copying file trees
> as root using "cp -p"?

That is a reasonable conclusion, but it is not feasible.  Unconditionally
requiring the preservation of each file's SELinux context would
result in unacceptably frequent non-zero exit status from the likes
of cp -p and cross-partition mv.  That would be seen as a regression.
Determining automatically when to attempt to preserve SELinux context,
and when it is not feasible to do so, is not tractable.

BTW, POSIX already specifies what cp -p must copy.  If cp cannot copy
some required-to-copy attribute, POSIX says how it must fail.  Hence,
I think it is inappropriate to make cp -p fail for some new reason like
failure to preserve SELinux context.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils