Re: file size listings in GnuWin32 coreutils 5.2.1 doesn't seem right
Thanks for your very detailed bug report. I can't reproduce the problems you mentioned with coreutils 5.3.0 (a test version) on Debian GNU/Linux 3.0, so for now I'll assume that the bugs are either fixed, or are specific to your platform. Have you contacted the people who ported the package to your platform? If the problems are related to the Microsoft Windows environment they might be a better source for help than bug-coreutils (which is the main upstream developers). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: md5sum
"Wilson, Jessica" <[EMAIL PROTECTED]> writes:
> Is there an updated version to the code I can download? When executing
> on a 2GB or larger file the checksum does not work. Do you know where I
> could possibly get a later version of this code?
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz
It should work fine with large files like that, assuming it gets
compiled correctly. ("configure" is supposed to figure out
automatically how to do this.)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
file size listings in GnuWin32 coreutils 5.2.1 doesn't seem right
Hi, I've downloaded and installed GnuWin32 coreutils 5.2.1 on 3/22/3005. My filesystem is NTFS and it was formatted with a block size of 4096 bytes. I have Windows 2000 with all of Microsoft's patches on a Pentium 4. I've experimented with ls, vdir, and du to see if I could get a listing of a file's actual size and can't see how to do it. the --help option for ls says "--block-size=SIZE use SIZE-byte blocks" but when I put "--block-size=1" to get a listing in single byte sizes (blocks in a size of 1 byte), I get some other result. I don't have any of the block size related environment variables set that are mentioned in the coreutils help file. For example I have a file "fontagent.zip" that is 1,260,452 bytes in size according to Microsoft's dir command. The command "ls --block-size=1 -s fontagent.zip" shows a size of 1,261,568 (which is how many 4K sized blocks it would take up, right?). Putting other values in for block-size doesn't seem to work right either. It really freaks out on some values, and crashed with "ls --block-size=140 -s -1". I made a seven byte file called "test.txt" and did the command "ls -s -1 test.txt" and it returned a size of 4 somethings. I don't think that is bytes (it would have been 7) or blocks (4*4096 is 16384 bytes). I've no idea what it is. The command "ls --block-size=1 -s -1 test.txt" returns a size of 4096. I had specified 1 byte blocks so it should have been a size of 7 instead. OK but that is the number of bytes in my filesystem's default block size, so I did the command "ls --block-size=4096 -s -1 test.txt" and got a size of 1. OK that seems right, a seven byte file fits in one 4K block. I tried the command "ls --block-size=7 -s -1 test.txt" and got a size of negative zero somethings. That doesn't seem right. At the least I would have expected a size of 1 block (one seven byte block). The command "ls --block-size=8 -s -1 test.txt" gives me a size of 512 somethings. Well, I could have accepted 1 block (a seven byte file will fit inside an eight byte block) but why is it doing math (4096/8=512) instead? The command "ls --block-size=4097 -s -1 test.txt" gives me postive zero somethings, not a size 1 block. Entering other values was kind of entertaining, like "ls --block-size=5 -s -1 test.txt" returning a size of -8227522786606030200 somethings. Why not 2 blocks (one seven byte file fits in 10 bytes worth of five byte blocks)? I'm not a programmer, so I think that is about the best that I can do to show the difference between what is displayed by the commands vs. what I expected them to display. The help file for coreutils says in the section about block sizes: "If none of the above environment variables are set, the block size currently defaults to 1024 bytes in most contexts, but this number may change in the future. For ls file sizes, the block size defaults to 1 byte. A block size specification can be a positive integer specifying the number of bytes per block, or it can be human-readable or si to select a human-readable format" This doesn't seem to be true in my case. Of course, maybe I just don't understand what the option --block-size is used for or maybe I just have the wrong kind of expectations? Also, with "ls -si -1" I get some large number listed before each row of file blocks and filename. I'm not sure what that is, since it doesn't show with "ls -s -1" and since the -i I believe is supposed to take the file blocks and round them to the nearest kilobytes, megabytes, etc. to make it "human friendly". Thanks, Stephen Carpenter [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -Iseconds isn't ISO 8601 / RFC 3339
Thanks for the very helpful and complete answer. After careful study, I agree with your analysis, I couldn't find it in the prose but the ISO 8601 ABNF in Appendix A does clearly show the ":" as optional. If this should turn out to be a recurring question, it might be worth mentioning in the docs, but I'm going away completely satisfied:-). -Bennett pgp52rYZcRPVR.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
md5sum
Is there an updated version to the code I can download? When executing on a 2GB or larger file the checksum does not work. Do you know where I could possibly get a later version of this code? Regards, Jessica 281-518-6228 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [patch] who and stale utmp entries
Tim Waugh <[EMAIL PROTECTED]> writes: > Here is a patch to prevent the who(1) command showing stale utmp > entries of user logins. That patch has a problem when process-IDs are reused. Can you please explain more what is going on here? As I understand it, "users" and "pinky" do not suffer from the stale-utmp problem. They do not invoke kill(), so they must have a method that doesn't involve testing whether a process-ID exists. Can we modify "who" to use their method? Also, does that patch attempt to send signals even when "who" is invoked as (say) "who -q file"? That doesn't sound quite right. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -l column alignment RHEL (4.5.3)
"Rob" <[EMAIL PROTECTED]> writes: > Is the output of ls -l supposed to be aligned as far as the timestamp and > filenames columns are concerned Yes. This is fixed in a different way, starting with coreutils 5.1.0. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: PATCH to enable reading of \r\n Newlines in md5sum
David Bridson wrote:
Hi!
I just ran into a problem checking an md5 file with \r\n line endings.
md5sum checks for \n line endings but not \r\n so, where an \r\n is
present, tries to fopen the correct filename with a \r appended. Here's
a simple patch to fix the problem.
Cheers,
Dave
--- coreutils-5.3.0/src/md5sum.c2004-09-20 08:40:39.0 +0100
+++ coreutils-updated/src/md5sum.c2005-03-23 16:48:16.0 +
@@ -433,7 +433,17 @@
/* Remove any trailing newline. */
if (line[line_length - 1] == '\n')
-line[--line_length] = '\0';
+{
+ if (line[line_length - 2] == '\r')
+{
+ line[--line_length] = '\0';
+ line[--line_length] = '\0';
+}
+ else
+{
+ line[--line_length] = '\0';
+}
+}
if (! (split_3 (line, line_length, &hex_digest, &binary, &filename)
&& hex_digits (hex_digest)))
Yuck! couldn't you just do:
if (line[line_length - 1] == '\n')
line[--line_length] = '\0';
if (line[line_length - 1] == '\r')
line[--line_length] = '\0';
That would handle the mac case also.
I'm not sure this is even required though.
What if you filename did end with '\r' ? unlikely but...
You can always `tr -d '\r'` the file first.
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -Iseconds isn't ISO 8601 / RFC 3339
> Needs a ":" in the middle of the timezone offset. > > -Bennett According to RFC 3339, the ISO 8601 grammar allows the ':' of a timezone offset to be optional, it is only RFC 3339 that requires it. Furthermore, ISO C and POSIX both require that strftime()'s implementation of %z omit the ':'. So we have a classic case of conflicting specifications. But note that `date --help' and `info coreutils date' do not lie - they only claim compliance with ISO 8601 and not with RFC 3339, and the -I option outputs the offset using %z. At this point, you could try to raise the issue with POSIX, and try to get a new % specification added (how about %o for offset?) that is like %z but adds the ':' in the middle. In the meantime, you could propose a patch to gnulib's lib/strftime.c that adds %o as a GNU extension. Also, you could raise the issue with the IETF that RFC 3339 is not easily implementable with the current POSIX spec. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
PATCH to enable reading of \r\n Newlines in md5sum
Hi!
I just ran into a problem checking an md5 file with \r\n line endings. md5sum checks for
\n line endings but not \r\n so, where an \r\n is present, tries to fopen the correct
filename with a \r appended. Here's a simple patch to fix the problem.
Cheers,
Dave
--- coreutils-5.3.0/src/md5sum.c2004-09-20 08:40:39.0 +0100
+++ coreutils-updated/src/md5sum.c 2005-03-23 16:48:16.0 +
@@ -433,7 +433,17 @@
/* Remove any trailing newline. */
if (line[line_length - 1] == '\n')
- line[--line_length] = '\0';
+{
+ if (line[line_length - 2] == '\r')
+{
+ line[--line_length] = '\0';
+ line[--line_length] = '\0';
+}
+ else
+{
+ line[--line_length] = '\0';
+}
+}
if (! (split_3 (line, line_length, &hex_digest, &binary, &filename)
&& hex_digits (hex_digest)))
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: install(1) man page
Rene Kapeller wrote: > Option '-C' is missing in the man page of install(1), neither does > 'install --help' list this option. Uhm... Neither does it appear in the source code. So all of that is consistent. install -C install: invalid option -- C Try `install --help' for more information. install --version install (coreutils) 5.2.1 Written by David MacKenzie. Copyright (C) 2004 Free Software Foundation, Inc. What version are you using? Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
install(1) man page
Option '-C' is missing in the man page of install(1), neither does 'install --help' list this option. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date -Iseconds isn't ISO 8601 / RFC 3339
Needs a ":" in the middle of the timezone offset. -Bennett pgpc85jIjF1L9.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch] who and stale utmp entries
Hi,
Here is a patch to prevent the who(1) command showing stale utmp
entries of user logins.
Tim.
*/
--- coreutils-5.2.1/src/who.c.stale-utmp2005-03-23 13:43:55.0
+
+++ coreutils-5.2.1/src/who.c 2005-03-23 13:46:44.0 +
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include
#include "system.h"
@@ -521,7 +523,8 @@
while (n--)
{
- if (UT_USER (utmp_buf)[0] && UT_TYPE (utmp_buf) == USER_PROCESS)
+ if (UT_USER (utmp_buf)[0] && UT_TYPE (utmp_buf) == USER_PROCESS &&
+ !(kill(utmp_buf->ut_pid, 0) < 0 && errno == ESRCH))
{
char *trimmed_name;
@@ -567,7 +570,8 @@
strncmp (ttyname_b, utmp_buf->ut_line,
sizeof (utmp_buf->ut_line)) == 0)
{
- if (need_users && IS_USER_PROCESS (utmp_buf))
+ if (need_users && IS_USER_PROCESS (utmp_buf) &&
+ !(kill(utmp_buf->ut_pid, 0) < 0 && errno == ESRCH))
print_user (utmp_buf);
else if (need_runlevel && UT_TYPE (utmp_buf) == RUN_LVL)
print_runlevel (utmp_buf);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
Hello,
I use debian sarge for alpha processor.
My installation contains coreutils 5.2.1 and I note
that du utility doesn't count correctly disk usage
for directory over 4GB.
For example I have a directory sarge-20041016
that contains a DVD iso image. The output of
"ll" is the following and it reports fine filesize.
alpha:/mnt/sdd2# ll sarge-20041016
total 4544832
-rw-r--r-- 1 tullio tullio 4653907968 Oct 16 05:10 sarge-alpha-1.iso
If I type du, I see the following output
alpha:/mnt/sdd2# du -s *
350528 sarge-20041016 <--- du displays only ~ 350MB
alpha:/mnt/sdd2#
So I searched in coreutils source file where du calculates used space
and I have tried this simple solution:
--- coreutils-5.2.1/src/du.c.orig 2005-03-22 23:22:58.740931368 +0100
+++ coreutils-5.2.1/src/du.c2005-03-23 12:56:36.854330472 +0100
@@ -382,7 +382,7 @@
{
size = (apparent_size
? sb->st_size
- : ST_NBLOCKS (*sb) * ST_NBLOCKSIZE);
+ : (uintmax_t)ST_NBLOCKS (*sb) * ST_NBLOCKSIZE);
}
if (first_call)
I think the real problem is * operation that exceed some 32 bit wide type.
On my alpha system sizeof returns:
sizeof(int)=4 byte
sizeof(long)=8 byte
sizeof(long long)=8 byte
sizeof(uintmax_t)=8 byte
Thanks,
tullio
6X velocizzare la tua navigazione a 56k? 6X Web Accelerator di Libero!
Scaricalo su INTERNET GRATIS 6X http://www.libero.it
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
