Prev: copy a file while it is actively being written
Next: Mobile Phone Compatibility = Dead End
From: Nuno J. Silva on 2 Feb 2010 18:08
Greg Russell <me(a)invalid.com> writes:

> On Tue, 02 Feb 2010 22:12:28 +0000, Grant Edwards wrote:
>
>>> Will someone explain please why these files differ after I just cp'd
>>> them? The file sizes are about 4.4 GB:
[...]
>> Either the "cp" didn't work or the "diff" didn't work.
>>
>> What does "cmp" say about the files?
>
> $ cmp -l ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso
> 1827673645 207 217
> 4243191341 263 273
>
> ... so apparently the "diff" output was correct. I can't imagine why the
> cp would fail with no stderr.

It should catch errors it knows about. If anything bad happens in memory
or in the storage device, it won't be detected.

You might have bad memory modules (which can corrupt data stored on
them), a bad disk (optical, magnetic, flash, ...), or even a bad data
cable.

--
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg
From: The Natural Philosopher on 2 Feb 2010 18:04
Greg Russell wrote:
> On Tue, 02 Feb 2010 22:40:15 +0000, The Natural Philosopher wrote:
>
>> Greg Russell wrote:
>>> On Tue, 02 Feb 2010 22:12:28 +0000, Grant Edwards wrote:
>>>
>>>>> Will someone explain please why these files differ after I just cp'd
>>>>> them? The file sizes are about 4.4 GB:
>>>>>
>>>>> $ diff ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso Binary files
>>>>> ./ssc_1992_highlights.iso and /tmp/ssc_1992/dvd.iso differ
>>>>>
>>>>> $ cp -v /tmp/ssc_1992/dvd.iso ./ssc_1992_highlights.iso
>>>>> `/tmp/ssc_1992/dvd.iso' -> `./ssc_1992_highlights.iso'
>>>>>
>>>>> $ diff ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso Binary files
>>>>> ./ssc_1992_highlights.iso and /tmp/ssc_1992/dvd.iso differ
>>>>>
>>>>> It's very confusing to me, and doesn't help the script execution
>>>>> we're trying to employ.
>>>> Either the "cp" didn't work or the "diff" didn't work.
>>>>
>>>> What does "cmp" say about the files?
>>> $ cmp -l ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso 1827673645 207
>>> 217
>>> 4243191341 263 273
>>>
>>> ... so apparently the "diff" output was correct. I can't imagine why
>>> the cp would fail with no stderr.
>> I don't think it has.
>
> Would you qualify that statement with your reasoning, please.
>
I'm not sure, bit I am wondering about sectors full of trash..i.e. the
actual linked list of data stops short of what the file size is marked
in the header block. Cos ISO's need to end on some kind of boundary.
So, Cp might finish, then update the file header block with the size
larger than the actual file data.

Then depending on what is in the unwritten over sectors, you will get
different results with diff or cmp.. Cos they might actually treat the
file in a slightly different way.

I think you can do the same thing at some levels by seeking past the end
of a file and writing..what's in between is 'indeterminate'.. the disk
subsystem in SOME systems will allocate blocks, but not clean them up.

This is all garnered from fragments of things I have noticed over the years.

At some subconscious level it prompted me to make that statement.




..

From: The Natural Philosopher on 2 Feb 2010 18:14
Nuno J. Silva wrote:
> Greg Russell <me(a)invalid.com> writes:
>
>> On Tue, 02 Feb 2010 22:12:28 +0000, Grant Edwards wrote:
>>
>>>> Will someone explain please why these files differ after I just cp'd
>>>> them? The file sizes are about 4.4 GB:
> [...]
>>> Either the "cp" didn't work or the "diff" didn't work.
>>>
>>> What does "cmp" say about the files?
>> $ cmp -l ./ssc_1992_highlights.iso /tmp/ssc_1992/dvd.iso
>> 1827673645 207 217
>> 4243191341 263 273
>>
>> ... so apparently the "diff" output was correct. I can't imagine why the
>> cp would fail with no stderr.
>
> It should catch errors it knows about. If anything bad happens in memory
> or in the storage device, it won't be detected.
>
> You might have bad memory modules (which can corrupt data stored on
> them), a bad disk (optical, magnetic, flash, ...), or even a bad data
> cable.
>
Further to my last post

http://en.wikipedia.org/wiki/ISO_9660

" * Level 1: File names are limited to eight characters with a
three-character extension, using upper case letters, numbers and
underscore only. The maximum depth of directories is eight.
* Level 2: File names are not limited to 11 characters (the 8.3
format) but can be up to the maximum allowed by the 1 byte counter in
the directory entry and the filename length byte counter. Typically,
this is close to 180 characters, depending on how many extended
attributes are present.
* Level 3: Files are allowed to be _non-contiguous_ (i.e.,
fragmented), principally to allow packet writing or incremental CD
recording).
"

If this is similarly represented at the Linux level in some way, it
implies that two perfectly valid ISO images could indeed have different
bytes in the 'gaps'
From: David W. Hodgins on 2 Feb 2010 18:20
On Tue, 02 Feb 2010 17:31:45 -0500, Greg Russell <me(a)invalid.com> wrote:

> ... so apparently the "diff" output was correct. I can't imagine why the
> cp would fail with no stderr.

Is the dest filesystem full? Check df.
Is the dest filesystem fat32, which has small file size limits?
Check mount.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: Nuno J. Silva on 2 Feb 2010 18:35
"David W. Hodgins" <dwhodgins(a)nomail.afraid.org> writes:

> On Tue, 02 Feb 2010 17:31:45 -0500, Greg Russell <me(a)invalid.com> wrote:
>
>> ... so apparently the "diff" output was correct. I can't imagine why the
>> cp would fail with no stderr.
>
> Is the dest filesystem full? Check df.

In that case, won't cp say something like "No space left of device"?

> Is the dest filesystem fat32, which has small file size limits?
> Check mount.
>
> Regards, Dave Hodgins

--
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: copy a file while it is actively being written
Next: Mobile Phone Compatibility = Dead End