Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 6/15/2009 10:24 AM: > Matej Cepl wrote: >> Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100: >>> http://www.pixelbeat.org/patches/gnulib-fallocate.diff >> Could I get a branch of it? I hate following patches... > > I'll look at creating a github branch, though for > this particular case it may be handier to patch > your own local branch. You can also push anonymously to my repo.or.cz clone, if you don't want to take the time to set up your own clone: git push m...@repo.or.cz:/srv/git/coreutils/ericb.git +HEAD:mob - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -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 iEYEARECAAYFAko2//oACgkQ84KuGfSFAYBPEACeMt+PSef6TB6MVzUi4lCdTkBN XREAoMfBJ9TA0esvKuJPXhDeuJSdC/WG =czRS -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: MAJOR Putty bug
[ re-adding bug-coreutils to keep discussion on-list ] On Mon, 15 Jun 2009, Derrick Manor wrote: sorry: using this basic command: chown username home/username/public_html/path_to_directory You've used example usernames and file paths here. Please give the exact command as it's typed, and the exact reply from chown. error message: can't find file/directory This is not an error message that chown prints. Please do not rephrase the output; simply paste it as it appears from chown. It's very likely that the file does not exist. Please check using "ls" that the filename and path are correct. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Can't chmod file
Derrick, Please keep the discussion on the mailing list. Use the "list-reply" feature of your mailer. Or if your mailer doesn't have that then use the "group follow-up" or "reply-to-all" feature. This way everyone can participate in the discussion and correct my mistakes. Also others who look for this later can learn from the discussion in the mail archives. Derrick Manor wrote: > yes. tells me that it can't find directory/file when i clearly have > path typed in there. It may be clear to you but to be clear to us you need to show us your exact commands. Otherwise I am biased to believe what the command is telling you. If the program says that the file isn't there then I believe that the file isn't there. > i was able to do it successfully yesterday adn the server changed > permissions back to default and now can't chown with Putty. A major > bug somewhere. So far I don't yet see a bug yet. Having much experience working with these types of issues with web servers most of the time it turns out to be simple confusion. In other words, don't just say that there is a bug. Instead please show us your problem. Show it to us exactly. Also putty doesn't have anything to do with changing the mode of a file. Putty is a terminal emulator with a built in ssh client. It doesn't change the mode of files. Putty is providing you with a terminal connected to your server. On your server you are running a command line shell and executing commands. The chmod command there is telling you that the file you are asking it to change doesn't exist. I believe the command's output that the file does not exist. Additionally the entire topic of file modes and file ownership and access capabilities when dealing with a remote web server isn't completely simple. Using history as a predictor I would guess that what you are doing is trying to open up permissions because the web server is running as a different user than installer. It may be possible that you really want to change the ownership of the file instead of the permission. Again, we don't know anything about what are you doing. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Can't chmod file (was: MAJOR Putty bug)
Derrick Manor wrote: > I am using, or trying to use Putty to change a file ownership on an > Apache server. You seem to be confusing putty with chmod. Those utilities are not related to each other. People looking at your subject line will believe that this thread is talking about putty when in reality you are asking about chmod. A reasonable subject line is important. Please read this reference: http://www.gnu.org/software/coreutils/faq/#How-do-I-report-a-bug_003f > However, the chown command does not work. Tells me there is no such > directory or file If the chmod command is telling you no such file or directory then the problem is that the file isn't there. The command can't change the mode of files that are not there. Go back and double check your filename. The problem is there. If you still don't see it then show us exactly the command you are executing. Cut and paste both the command and the output. So this as plain text (not as a graphics image) so that we can know what you are doing and what result you are getting. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: MAJOR Putty bug
On Mon, 15 Jun 2009, Derrick Manor wrote: I am using, or trying to use Putty to change a file ownership on an Apache server. However, the chown command does not work. Tells me there is no such directory or file There's not enough information to tell what's causing the problem here. Please let us know: - What did you do/type? - What happened? - What did you expect to happen? Feel free to copy and paste the commands and output into your email; it's easier to see what's happening from the exact record. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
MAJOR Putty bug
I am using, or trying to use Putty to change a file ownership on an Apache server. However, the chown command does not work. Tells me there is no such directory or file Just wanted to let you know so you can fix it. i will check for an update soon.. thanks. Derrick Manor ___ 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
Giuseppe Scrivano wrote:
...
> This is the new version:
>
> Subject: [PATCH] tail: Use inotify if it is available.
>
> * NEWS: Document the new feature.
> * m4/jm-macros.m4: Check if inotify is present.
> * src/tail.c (tail_forever_inotify): New function.
> (main): Use the inotify-based function, if possible.
> * tests/Makefile.am: Add new tests for tail.
> * tests/test-lib.sh (require_proc_pid_status_, get_process_status_):
> New functions.
> * tests/tail-2/pid: New file.
> * tests/tail-2/wait: New file.
> * tests/tail-2/tail-n0f: Refactor code into the test-lib.sh
> require_proc_pid_status_ function.
Thanks for persevering.
I've made a couple of tiny changes:
- log: first line: no capital. no trailing period
- one of tests: use TAB-space, not space-TAB in [...]
and finally have pushed the result.
>From ae494d4be80df2aff50a2ac46fdc0c23de109ea3 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Tue, 2 Jun 2009 08:28:23 +0200
Subject: [PATCH] tail: use inotify if it is available
* NEWS: Document the new feature.
* m4/jm-macros.m4: Check if inotify is present.
* src/tail.c (tail_forever_inotify): New function.
(main): Use the inotify-based function, if possible.
* tests/Makefile.am: Add new tests for tail.
* tests/test-lib.sh (require_proc_pid_status_, get_process_status_):
New functions.
* tests/tail-2/pid: New file.
* tests/tail-2/wait: New file.
* tests/tail-2/tail-n0f: Refactor code into the test-lib.sh
require_proc_pid_status_ function.
---
NEWS |2 +
m4/jm-macros.m4 |5 +
src/tail.c| 275 +++--
tests/Makefile.am |2 +
tests/tail-2/pid | 68
tests/tail-2/tail-n0f |9 +--
tests/tail-2/wait | 131 +++
tests/test-lib.sh | 16 +++
8 files changed, 493 insertions(+), 15 deletions(-)
create mode 100755 tests/tail-2/pid
create mode 100755 tests/tail-2/wait
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.
+
* Noteworthy changes in release 7.4 (2009-05-07) [stable]
diff --git a/m4/jm-macros.m4 b/m4/jm-macros.m4
index 90c55bf..f14d6a3 100644
--- a/m4/jm-macros.m4
+++ b/m4/jm-macros.m4
@@ -52,6 +52,11 @@ AC_DEFUN([coreutils_MACROS],
# Used by sort.c.
AC_CHECK_FUNCS_ONCE([nl_langinfo])
+ # Used by tail.c.
+ AC_CHECK_FUNCS([inotify_init],
+[AC_DEFINE([HAVE_INOTIFY], [1],
+ [Define to 1 if you have usable inotify support.])])
+
AC_CHECK_FUNCS_ONCE( \
endgrent \
endpwent \
diff --git a/src/tail.c b/src/tail.c
index 9d416e1..059ee82 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -21,7 +21,8 @@
Original version by Paul Rubin .
Extensions by David MacKenzie .
- tail -f for multiple files by Ian Lance Taylor . */
+ tail -f for multiple files by Ian Lance Taylor .
+ inotify back-end by Giuseppe Scrivano . */
#include
@@ -46,6 +47,11 @@
#include "xstrtol.h"
#include "xstrtod.h"
+#if HAVE_INOTIFY
+# include "hash.h"
+# include
+#endif
+
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME "tail"
@@ -125,8 +131,26 @@ struct File_spec
/* The value of errno seen last time we checked this file. */
int errnum;
+#if HAVE_INOTIFY
+ /* The watch descriptor used by inotify. */
+ int wd;
+
+ /* The parent directory watch descriptor. It is used only
+ * when Follow_name is used. */
+ int parent_wd;
+
+ /* Offset in NAME of the basename part. */
+ size_t basename_start;
+#endif
};
+#if HAVE_INOTIFY
+/* The events mask used with inotify on files. This mask is not used on
+ directories. */
+const uint32_t inotify_wd_mask = (IN_MODIFY | IN_ATTRIB | IN_DELETE_SELF
+ | IN_MOVE_SELF);
+#endif
+
/* Keep trying to open a file even if it is inaccessible when tail starts
or if it becomes inaccessible later -- useful only with -f. */
static bool reopen_inaccessible_files;
@@ -964,7 +988,7 @@ any_live_files (const struct File_spec *f, int n_files)
return false;
}
-/* Tail NFILES files forever, or until killed.
+/* Tail N_FILES files forever, or until killed.
The pertinent information for each file is stored in an entry of F.
Loop over each of them, doing an fstat to see if they have changed size,
and an occasional open/fstat to see if any dev/ino pair has changed.
@@ -972,22 +996,22 @@ any_live_files (const struct File_spec *f, int n_files)
while and try again. Continue until the user interrupts us. */
static void
-tail_forever (struct File_spec *f, int nfiles, double sleep_interval)
+tail_forever (struct File_spec *f, int n_files, double sleep_interval)
{
/* Use blocking I/O as an optimization, when it's easy. */
b
Re: Bug#532814: coreutils: cp -aL creates hardlinks where none were present before
[resending to bug-coreutils, not just to the debian bug tracker]
Jim Meyering wrote:
> brian m. carlson wrote:
>> Package: coreutils
>> Version: 7.4-2
>
> Thanks for taking the time to report that.
>
>> If I create a directory structure such as the following:
>>
>> a:
>> total 2
>> drwxr-xr-x 2 bmc bmc 1024 2009-06-11 21:06 dir
>> lrwxrwxrwx 1 bmc bmc4 2009-06-11 21:06 link -> ../b
>>
>> a/dir:
>> total 0
>> lrwxrwxrwx 1 bmc bmc 7 2009-06-11 21:06 link -> ../../b
>>
>> b:
>> total 2
>> -rw-r--r-- 1 bmc bmc 5 2009-06-11 21:06 file
>>
>> and then run "cp -aL a/* c", then the copies of file (in c) become hard
>> links to each other. This behavior is not documented, and it does not
>> occur if I use -LR instead of -aL. It appears to be triggered by
>> --preserve=links.
>
> That is correct, and deliberate.
> With --preserve=links, when cp detects two source files with the
> same inode, it must arrange for the corresponding names to be hard
> linked in the destination tree. That is what "preserve=links" means.
>
> The trick is to realize that when you invoke cp with -L,
> that tells cp to use stat (which never sees a symlink) rather
> than lstat to determine inode numbers. So those two symlinks
> to the same file appear (to cp -L) as hard links, and it preserves
> that attribute because you used -a, which includes --preserve=links.
>
>> My opinion is that this behavior is incorrect[0], but I don't care very
>> much one way or the other. If this behavior is intentional, it should
>> be clearly documented in the manual page, at the very least. Either
>> changing the behavior or documenting the behavior[1] is satisfactory for
>> me.
>
> I reproduced with this:
>
> $ mkdir c; touch f; ln -s f a; ln -s f b; cp -aL a b c; ls -i1 c
> 74161745 a
> 74161745 b
>
>> [0] That is, --preserve=links should preserve symlinks as symlinks and
>> hard links as hard links. Just because -L forces all symlinks to be
>> dereferenced does not mean that I want to "preserve" symlinks as hard
>> links.
>
> --preserve=links preserves *hard* links.
> By definition (POSIX), cp -L can never produce a symlink.
>
>> [1] This information should be present in the manual page, not just in
>> the info page (which I almost never read).
>
> Sorry, but this corner is obscure enough that any explanation
> belongs in the info documentation.
> In fact, there are already comments in the texinfo sources
> saying that this deserves explanation.
>
> I wrote a few words on -L and added to the --preserve=links description:
>
> `links'
> Preserve in the destination files any links between
> corresponding source files. Note that with `-L' or `-H',
> this option can convert symbolic links to hard links. For
> example,
>$ mkdir c; : > a; ln -s a b; cp -aH a b c; ls -i1 c
>74161745 a
>74161745 b
> Note the inputs: `b' is a symlink to regular file `a', yet
> the files in destination directory, `c/', are hard-linked.
> Since `-a' implies `--preserve=links', and since `-H' tells
> `cp' to dereference command line arguments, it sees two files
> with the same inode number, and preserves the perceived hard
> link.
>
> Here is a similar example that exercises `cp''s `-L' option:
>$ mkdir b c; (cd b; : > a; ln -s a b); cp -aL b c; ls -i1 c/b
>74163295 a
>74163295 b
>
> Here's the patch:
>
> From 7d350170ae78e1aca68aff81a08116109dd33be5 Mon Sep 17 00:00:00 2001
> From: Jim Meyering
> Date: Mon, 15 Jun 2009 09:10:50 +0200
> Subject: [PATCH] doc: cp: describe an oddity of combining -H/-L and
> --preserve=links
>
> * doc/coreutils.texi (cp invocation) [-L]: Elaborate.
> [--preserve=links]: Remove comments saying that we need documentation
> for just this situation. Provide more explanation and examples.
> Reported by Brian M. Carlson in http://bugs.debian.org/525048.
> ---
> doc/coreutils.texi | 26 --
> 1 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 155858b..1806295 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -7388,6 +7388,9 @@ cp invocation
> @opindex -L
> @opindex --dereference
> Follow symbolic links when copying from them.
> +With this option, @command{cp} cannot create a symbolic link.
> +For example, a symlink (to regular file) in the source tree will be copied to
> +a regular file in the destination tree.
>
> @item -n
> @itemx --no-clobber
> @@ -7435,8 +7438,27 @@ cp invocation
> @itemx links
> Preserve in the destination files
> any links between corresponding source files.
> -...@c Give examples illustrating how hard links are preserved.
> -...@c Also, show how soft links map to hard links with -L and -H.
> +Note that with @option{-L} or @option{-H}, this option can convert
> +symbolic link
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Matej Cepl wrote: > Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100: >> http://www.pixelbeat.org/patches/gnulib-fallocate.diff > > Could I get a branch of it? I hate following patches... I'll look at creating a github branch, though for this particular case it may be handier to patch your own local branch. back online in a few hours... Thanks again for looking at this! cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100: > http://www.pixelbeat.org/patches/gnulib-fallocate.diff Could I get a branch of it? I hate following patches... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Matej Cepl wrote: > Pádraig Brady, Sat, 13 Jun 2009 01:19:36 +0100: >> I was thinking that truncate --allocate would call posix_fallocate() >> which guarantees that the file is allocated even if the filesystem does >> not support fallocate(). I.E. we would need to add a posix_fallocate() >> gnulib module that adds the function if not available, and does what >> glibc does if fallocate() returns ENOSYS (write zeros). > > Could I hope in arrival of that anytime soon, or should I try to get > myself wet with blood of gnulib and make the patch myself? Please go ahead with copying the glibc posix_fallocate() to the posix_fallocate gnulib module. It would depend on the fallocate gnulib module, the latest version of which I'll keep here: http://www.pixelbeat.org/patches/gnulib-fallocate.diff There is an outstanding question on that interface here: https://bugzilla.redhat.com/show_bug.cgi?id=500487 but that shouldn't be blocking addition of the posix_fallocate module I think. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] stdbuf work in progress
Jim Meyering wrote:
> Pádraig Brady wrote:
>> http://www.pixelbeat.org/patches/stdbuf.diff
>
> Looking at the latest, I see this:
>
> + else
> +{
> + setvbuf_mode = _IOFBF;
> + /* Note this is done elsewhere in coreutils:
> + verify (SIZE_MAX <= ULONG_MAX); */
>
> Please drop the comment and just use verify here.
> The other test may disappear some day,
> and it costs nothing at run-time.
Of course. I wrote the comment so I would do this
when I integrated the lib to coreutils, but forgot
to add the FIXME tag and therefore missed it :p
> ---
>
> + size = strtoul (mode, NULL, 10);
> + if (size > 0)
> +buf = malloc (size);/* will be free by fclose() */
> + else
> +{
> + fprintf (stderr, _("invalid buffering mode %s for %s"),
> + mode, fileno_to_name (fileno (stream)));
>
> s/mode/quote (mode)/ in case it contains odd bytes.
Well I had quote() originally, but that required linking to
libcoreutils.a which causes the PIC linking errors on 64 bit.
>
> + return;
> +}
> +}
> +
> + if (setvbuf (stream, buf, setvbuf_mode, size) != 0)
>
> The comment above says never to call setvbuf with nonzero size
> and with buf == NULL. But if malloc fails, that's what happens.
Well the C99 standard says NULL buffers with non zero size are allowed.
GLIBC currently ignores this combination but may support it in future.
FreeBSD currently allocates a buffer internally on the first read/write
operation on the stream. So I thought it best to not error in this case
as it may actually succeed at a later point. But I changed it to
fail early as you suggest.
The rest of your comments were hopefully fixed also in the latest version:
http://www.pixelbeat.org/patches/stdbuf.diff
thanks!
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Pádraig Brady, Sat, 13 Jun 2009 01:19:36 +0100: > I was thinking that truncate --allocate would call posix_fallocate() > which guarantees that the file is allocated even if the filesystem does > not support fallocate(). I.E. we would need to add a posix_fallocate() > gnulib module that adds the function if not available, and does what > glibc does if fallocate() returns ENOSYS (write zeros). Could I hope in arrival of that anytime soon, or should I try to get myself wet with blood of gnulib and make the patch myself? Matěj ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Eric Sandeen, Sun, 14 Jun 2009 23:38:34 -0500: > I'd personally rather see a separate, dedicated fallocate tool ... but > maybe that's just me. You might run it by the fsdevel-list, or maybe > I've bike-shedded enough already. :) I still have in my patch and I plan to push into coreutils (if possible) mkfile script which would be command line compatible with mkfile on other Unices. Would it make you happy? Matěj ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up
Eric Sandeen wrote: > Pádraig Brady wrote: > > ... > >> On a related note it looks like fallocate64() which is required >> on 32 bit systems will not be supported in glibc-2.10 as it >> was released as a glibc-2.11 symbol. That means that 32 bit `cp` >> built on glibc-2.10 will not allocate extents for a file, >> and likewise 32 bit `truncate --allocate` will resort to writing >> zeros when built on glibc-2.10. > > > Sorry for ignoring this thread and then chiming in late... but at least > for myself, "truncate --allocate" is a bit confusing. At least in the > filesystem world, truncating and allocating are pretty much orthogonal, > so making a tool called "truncate" which has an "allocate" mode is a bit > odd to me. It'd be kind of like having a "ls --du" command option. > > I'd personally rather see a separate, dedicated fallocate tool ... but > maybe that's just me. You might run it by the fsdevel-list, or maybe > I've bike-shedded enough already. :) I agree if starting now we would not call the syscall or util truncate. However these have been in existence for ages. I.E. truncate sets the apparent size of the file, so adding a --allocate option to set the actual size (disk usage) seems justified. Note FreeBSD also has a truncate utility. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
