Jim Meyering wrote:
Linda A. Walsh wrote:
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that users of
the core utilis
Linda A. Walsh wrote:
...
But that's not the bug db interface...thats just a log...where? the bug
db intface for the bug in the bug database?
References
1. http://bugs.gnu.org/10055
Here's a description of the interface:
http://debbugs.gnu.org/
Original Message
Subject: [sr #107875] BUG cp -u corrupts 'fs'' information if
interupted; can't recover on future invoctions
Date: Tue, 15 Nov 2011 17:58:23 +
From: Linda A. Walsh invalid.nore...@gnu.org
To: Linda A. Walsh
URL:
http://savannah.gnu.org
Thanks for your thoughtful suggestions.
I like many of the ideas and hope that somebody can find the time
to code them up. Here are some more-detailed comments.
On 11/15/11 11:07, Linda Walsh wrote:
3). use posix_fallocate (if available) to allocate sufficient space for the
copy
This seems
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial copy than no copy at all. As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want A removed on interrupt
Paul Eggert wrote:
A) catch INT ( catchable signals), and remove any files that are
'incomplete'
That might cause trouble in other cases. For example, cp A B where
B already exists.
===
Am **only** suggesting this where 'B' has already been opened
and truncated by stuff being
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that
users of
the core utilis are ot allowed to find bugs...convenient.
.
Not a bad idea and least invasive, but if the Ctrl-C happened
between the creat() and utime() you'd get a newer zero length file.
Then subsequent `cp -u` would have to treat zero length files specially.
cheers,
Pádraig.
Paul Eggert wrote:
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial copy than no copy at all. As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want A
[Thought I send out rspns to this, but can't find it in my outgo,
so...recomposing/sending,
sorry for delay)
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial
On 11/15/11 19:33, Linda A. Walsh wrote:
Why don't we
focus on the specific problem mentioned which was using it in the context of
the -u flag, (and with -a/-r and/or a wildcard), where you expect it to
update
contents of 'Dst' with 'Src'.
I'd rather not have a heuristic that says cp
Linda A. Walsh wrote:
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that users
of
the core utilis are ot allowed to
Hi,
Is it a bug or a feature that cp -u reports an error when a file is
being
copied over itself -- supposedly such a file is not subject for an
update (as it is not newer than the destination, which is itself),
so it would have seemed than cp should not care of such a file, but
it does still
Ed Avis [EMAIL PROTECTED] wrote:
% touch foo foo
% cp -u foo foo echo yes
cp: `foo' and `foo' are the same file
I expected that since -u says
-u, --update
copy only when the SOURCE file is newer than the
destination file or when the destination file
% touch foo foo
% cp -u foo foo echo yes
cp: `foo' and `foo' are the same file
I expected that since -u says
-u, --update
copy only when the SOURCE file is newer than the
destination file or when the destination file is missing
it would not attempt to copy
Hi!
I'm using Ubuntu version 8.04, kernel 2.6.24-19-generic. I have done some
simple backups of directories using 'cp -u' that updates the files, if
source is newer than the destination (or if destination file is missing).
I noticed that if, for some reason, the copy of a file is interrupted
Markku A. Mähönen [EMAIL PROTECTED] writes:
So I would like to suggest that 'cp -u' should also check the size of the
files and do a copy if source is newer, or if destination is missing, or if
file sizes are different.
A much better way to do what you want is to use rsync, which offers even
On Sat, 14 Jun 2008, Markku A. Mähönen wrote:
I noticed that if, for some reason, the copy of a file is interrupted
(and so the destination file is not the same size as the source) and
after that you do 'cp -u' again it does not update the interrupted
file. So the 'cp -u' does not care about
2008/6/14 Philip Rowlands [EMAIL PROTECTED]:
You might find rsync to be a better tool for this task. It's more robust
against partial-copy failures, and has the nice property that copied files
will all carry the same mtime, whereas cp -u will not attempt to replicate
timestamps (from
Markku A. Mähönen wrote:
2008/6/14 Philip Rowlands [EMAIL PROTECTED]:
You might find rsync to be a better tool for this task. It's more robust
against partial-copy failures, and has the nice property that copied files
will all carry the same mtime, whereas cp -u will not attempt
get the exit code, if the system boots while 'cp -u'
/M
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Markku A. Mähönen wrote:
You don't get the exit code, if the system boots while 'cp -u'
At that point the computational model of the machine is broken and
there isn't anything that will protect you against file corruption.
But you mentioned interrupted and therefore normal SIGINT came to
mind
2008/6/14 Bob Proulx [EMAIL PROTECTED]:
Markku A. Mähönen wrote:
You don't get the exit code, if the system boots while 'cp -u'
At that point the computational model of the machine is broken and
there isn't anything that will protect you against file corruption.
But you mentioned
58 00 24 16 58 58 02 34
--all TWO seconds, (so they are always even numbers above.)
This means that
set /non-vfat/file /vfat/file
$ cp -p $1 $2 #if done during an odd-numbered second of time,
$ cp -u $1 $2 #will cause this second line to wastefully fire again.
So please investigate your claim
JM It'd be great if you would suggest wording to document this discrepancy.
The wording is fine as is.
The problem is that you don't act according to your wording.
You think truncate fractional seconds, using one-second buckets to compare,
whereas you need to use two-second buckets to compare if
[EMAIL PROTECTED] wrote:
JM It'd be great if you would suggest wording to document this discrepancy.
The wording is fine as is.
The problem is that you don't act according to your wording.
You think truncate fractional seconds, using one-second buckets to compare,
whereas you need to use
JM - document a subtle limitation encountered when using a losing file system
It's the Lingua Franca of USB filesystem where I live.
You change your comparison from
Modify: 2008-04-03 05:45:22.7
to one second buckets
Modify: 2008-04-03 05:45:22
so it should be just as easy to add a two
it should be just as easy to add a two second bucket too
Sorry, but as far as I know, it's not easy at all, in the context of cp.
Keep this in perspective: i.e., what's the penalty for
not changing the code to match the documentation?
The second cp -u invocation in the right two-second interval
All I know is your program is guilty of conspiracy to wear out people's
USB flash cards.
If FAT is detected, just run source and destination times thru a chopper like
$ m=$(date +%s); echo -n $m--\; expr $m / 2 \* 2
1207175575--1207175574
and cp -u will never blow it again, innocent of any future
, (so they are always even numbers above.)
This means that
set /non-vfat/file /vfat/file
$ cp -p $1 $2 #if done during an odd-numbered second of time,
$ cp -u $1 $2 #will cause this second line to wastefully fire again.
So please investigate your claim that
the comparison is to the source time
30 matches
Mail list logo
