I had to make the changes by hand. My version of patch did not
understand your change. The change did not work.
I've attached a gziped tar file with the three things you asked for.
I just captured the stdout and stderr of the make and sent you the
end of it for the last item. I hope
Paul Eggert wrote:
Matthew Woehlke [EMAIL PROTECTED] writes:
Notice that it looks like the result of 'xy' under certain
circumstances is '0x1 | (x 0x)', regardless of the
value of 'y'... which is of course Just Plain Wrong.
That's what we're looking for. Ideally, I'd like a
Matthew Woehlke [EMAIL PROTECTED] writes:
Nope, no luck, '0' in both cases, and adding a printf confirms the
correct values.
Can you strip down intparam1.c to relatively small test case that
illustrates the problem?
___
Bug-coreutils mailing list
The mtime of a file is not copied fully when -a option is
invoked. This can be seen only when --full-time is used to display the
original and the copied files. In particular the last three digits of
the copy mtime (the nano-seconds part) are always zero in the copy.
This plays nasty when one
Perry Smith [EMAIL PROTECTED] wrote:
On Oct 17, 2006, at 11:24 AM, Paul Eggert wrote:
...
Sorry, nothing was attached in the email I received. Can you
please resend it to [EMAIL PROTECTED] Thanks.
Try this again.
Still no attachment.
___
Perry Smith [EMAIL PROTECTED] writes:
I sent it to myself as well and I got the attachment. Looking in my
outbox, the attachment is on all three notes.
Very strange. I didn't get the attachment in either of the
two emails you sent via the bug-coreutils@gnu.org mailing list.
Looking at the
If
`install' is similar to `cp', but allows you to control the
attributes of destination files. It is typically used ... to copy
programs into their destination directories.
Then it is ripe for adding new functionality:
--hardlink make hard links instead of copying
(And maybe even
Paul E Condon [EMAIL PROTECTED] writes:
The mtime of a file is not copied fully when -a option is
invoked. This can be seen only when --full-time is used to display the
original and the copied files. In particular the last three digits of
the copy mtime (the nano-seconds part) are always zero
Let me know if that made it through (and it is what you need).
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Paul Eggert wrote:
Perry Smith writes:
I sent it to myself as well and I got the attachment. Looking in my
outbox, the attachment is on all three notes.
Very strange. I didn't get the attachment in either of the
two emails you sent via the bug-coreutils@gnu.org mailing list.
I checked
Paul E Condon wrote:
However, it does NOT set the mtime the full precision when
files are extracted from the .tar file. It only restores
the integral part of the second. The fractional part is all
zeros.
Perhaps if both cp and tar are doing the same thing then the problem
is outside the
11 matches
Mail list logo
