diif -qr input/output error
 

garrett@mint-desktop ~ $ diff -qr ~/Music/ /media/garrett/6BF6-AC8A
Only in /home/garrett/Music/Coldplay: A Rush of Blood to the Head
diff: /media/garrett/6BF6-AC8A/Collective Soul/Afterwords/02. What I Can Give You.flac: Input/output error

I got the above while trying to test the difference between my music library and my SDcard. What I'd like to know is did diff stop running after it hit the Input/output error or did it finish the complete check and then output the error message?

I would say diff is not really usable for binary files, it tries to compare files line by line.
You can check the man page of diff: Exit status is 0 if inputs are the same, 1 if different, 2 if trouble. I assume you got 2 and that means you cannot rely on the output after that (but I'm not really sure, I found no information)

Use cmp for comparing binaries.

I need to step down recursively through all the directories to compare my music file, I don't see a recursive option for cmp.

that will not make diff work for you. There is a tool dupfinder probably that would be a better option for you.
http://sourceforge.net/projects/doub...atest/download

You can run diff with the "-q" (--brief) option, which will simply report whether files differ. Then there should be no problem with binary files.

The problem with the I/O error will still be there because that file (presumably on the SD card) is simply unreadable. There should be some error message in the system logs with more details.

That's what shell scripts are for. In a script, you would also have control over the recursion and ensure that the program doesn't stop when it encounters a file with errors.

On the other hand, it seems that diff -qr is a viable solution, and pan64's remark about the exit code is the answer to your question.

You could try generating checksums eg MD5, sha1, whatever, for each file and compare those?

It depends on what you are trying to do. If you have two directory trees that should be identical with matching content in the files, then "diff -rq" is the simplest tool for the job. If you're looking for files with identical content that are located in different places in the directory tree and perhaps with different names, then matching MD5 sums or a tool like dupfinder is what you need. It seems to me that the OP was doing the former.

this may yeild an answer

$ strace diff -qr ~/Music/ /media/garrett/6BF6-AC8A

> I got the above while trying to test the difference between my music library and my SDcard. What I'd like to know is did diff stop running after it hit the Input/output error or did it finish the complete check and then output the error message?

consider running LFS. you can look at the source to know when the VERY SAME text error message is printed and even modify it

C programming language binaries. they have ASM startup code that runs after linux loader copies binary into memory (it fills in some offset pointers and options too)

the startup code initiates interrupts and opens some stream files (stdio) /dev/stdout, /dev/stderr

you saw the message but if it was in a stream it may have been printed at ANY TIME: so you are right! you do not know just by seeing the terminal text when the message printed: it may have been stderr or stdout. stderr does not "sync" when stdout does they are asynchronous. you dont even know (unless in the C code fflush(stderr) is used) that while processing some interrupt if stdout file stream was not held before / during / after an io error.

they are file streams (not direct io) and are processed "as soon as is convenient", thus they are very efficient and the programmer does not have to do a thing but use printf("hello world\n") to get excellent unix io. but what unix users/programs do have to keep in mind is "race conditions". it's a world of asynchronous times. if you ever want to know times "in different worlds" you have to have a "lock", a spin lock, you have to have a hard reference and check against it, to avoid "race conditions".

here the race condition is your question: did the chicken or egg print first?

berndbausch I'm confused. First you says that diff -qr is a viable option and then you say that that pan64's answer is good and he said "that will not make diff work for you". Also, diff -qr is exactly the option I tried and it's the very fist thread on this discussion.

I said pan64's answer about the exit code: "You can check the man page of diff: Exit status is 0 if inputs are the same, 1 if different, 2 if trouble. I assume you got 2 and that means you cannot rely on the output after that (but I'm not really sure, I found no information)"

To be sure, you would need to use strace (as debguy suggested) or examine the source, but I would say it's 90% likely that diff simply stopped when it encountered the I/O error and did not examine other files.