On Sat, 22 Oct 2005, Dave Richards wrote:
>If you accidentally use unlink on a real file, it won't do anything to
>it.
Not true. unlink is quite happy to delete real files; I'd even suggest
rm is safer, as it will prompt in certain circumstances where unlink
won't (--interactive or write-protecte
Jim Meyering wrote:
It sounds like a problem with an underlying driver.
I'm doubt it's worth trying to work around in dd. Besides,
what can dd do? If you request a block size of 32, it can't
very well opt to use 512 because using 32 might make hang a
buggy driver.
Yeah I agree, doesn't seem
Curt Blank <[EMAIL PROTECTED]> wrote:
> Just curious, are you going to follow up and try to make it work again
> or let it go?
It sounds like a problem with an underlying driver.
I'm doubt it's worth trying to work around in dd. Besides,
what can dd do? If you request a block size of 32, it can'
Just curious, are you going to follow up and try to make it work again
or let it go?
I see what you mean, the perl script does this:
read(3, "bb 2005-10-21T21:35:06-0500 "..., 4096) = 512
Then this:
write(1, "bb 2005-10-21T21:35:06-0500 ", 32) = 32
Jim Meyering wrote:
Curt Blank <[
Curt Blank <[EMAIL PROTECTED]> wrote:
> Ok, it appears to definitely be a blocking factor issue.
...
> So I'm starting to think it might not be dd problem in and of itself. My
...
Thanks for the follow-up.
I agree that this is almost certainly not a problem with dd itself.
If you want to see why
Ok, it appears to definitely be a blocking factor issue.
One thing I should mention, when the read was hanging while doing the
strace it was hung on the read(0, 0x8055000, 32), all I saw while
cat'ing out the log file while it was hanging was read(0 at the end.
I padded the "if" file out to 5
Mikulas Patocka <[EMAIL PROTECTED]> writes:
Intel compiler's interprocedural optimizations (-ipo) optimizes this
out even though the symbol is unknown.
Wonderful. (:-)
I installed the following patch to try to catch this.
The compilation gets a bit further with the patch, but it still does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to stephen bozarth on 10/21/2005 8:52 PM:
> # ./configure > configure.result
> configure: WARNING: sys/mount.h: present but cannot be compiled
> configure: WARNING: sys/sysctl.h: present but cannot be compiled
Thanks for the bug report. How
The logs are attached. as you can see below the read never completed and
the write outright failed. I was able to get dd to exit the read by
unloading the tape via the front panel of the library after 15 some minutes.
Originally I said dd hangs, it appears to only hang on the read and
fails on
# ./configure > configure.result
configure: WARNING: sys/mount.h: present but cannot be compiled
configure: WARNING: sys/mount.h: check for missing prerequisite headers?
configure: WARNING: sys/mount.h: see the Autoconf documentation
configure: WARNING: sys/mount.h: section "Present But Ca
I'll do that first thing tomorrow, my backup is about to kick off at
02:00. I had hoped I provided a good amount of information to get
started, and thanks. I found a way to label tapes without dd. My first
attempt with perl could read existing labels but could not write them. I
then moved to C
Hello I'm GNU webmaster and your manual page
(http://www.gnu.org/software/coreutils/manual/) has one broken link
Info document
(http://www.gnu.org/software/coreutils/manual/info/coreutils-info.tar.gz)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 10/18/2005 6:36 AM:
>
> Meanwhile, there are a few bugs I found. I can provide a patch, but need
> some agreement on semantics first.
One more to get consensus on. Right now,
$ echo $TERM
xterm
$ dircolors - >/dev/null
i
Bob-
Thanks for your thoughts on this issue. The reason for using this
command (and teaching our support staff to use it) is not technical but
just to reduce 'human error' and for comfort level.
- Sometimes people perceive that 'rm' is deleting the file and not just
the symbolic link. I get
14 matches
Mail list logo
