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
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
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] 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: 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 meyer...@redhat.com
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 links to hard links. For example,
+...@example
+$ mkdir c; : a; ln -s a b; cp -aH a b c; ls -i1 c
+74161745 a
+74161745 b
+...@end example
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 gscriv...@gnu.org 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 p...@ocf.berkeley.edu. Extensions by David MacKenzie d...@gnu.ai.mit.edu. - tail -f for multiple files by Ian Lance Taylor i...@airs.com. */ + tail -f for multiple files by Ian Lance Taylor i...@airs.com. + inotify back-end by Giuseppe Scrivano gscriv...@gnu.org. */ #include config.h @@ -46,6 +47,11 @@ #include xstrtol.h #include xstrtod.h +#if HAVE_INOTIFY +# include hash.h +# include sys/inotify.h +#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
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: 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
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: 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
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
