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 co
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 c
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 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
I just did some similar tests of tar:
tar appears to store a correct, full precision mtime in a .tar
file, and use that full precision mtime when deciding whether
to write a new copy of a file when processing -u option.
However, it does NOT set the mtime the full precision when
files are extracte
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
--
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 th
I sent it to myself as well and I got the attachment. Looking in my
outbox, the attachment is on all three notes.
On Oct 17, 2006, at 1:40 PM, Perry Smith wrote:
On Oct 17, 2006, at 1:39 PM, Jim Meyering wrote:
Perry Smith <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 11:24 AM, Paul Egg
On Oct 17, 2006, at 1:39 PM, Jim Meyering wrote:
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]> 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.
__
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 attem
On Oct 17, 2006, at 11:24 AM, Paul Eggert wrote:
Perry Smith <[EMAIL PROTECTED]> writes:
I had to make the changes by hand. My version of patch did not
understand your change. The change did not work.
Too bad.
I've attached a gziped tar file with the three things you asked for.
Sorry,
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 lis
Perry Smith <[EMAIL PROTECTED]> writes:
> I had to make the changes by hand. My version of patch did not
> understand your change. The change did not work.
Too bad.
> I've attached a gziped tar file with the three things you asked for.
Sorry, nothing was attached in the email I received. Can
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
Notice that it looks like the result of 'x>>y' 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 li
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 tha
16 matches
Mail list logo
