Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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)
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.
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'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.
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.
> 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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.