Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm trying to move a file from my desktop computer to my laptop computer (both with Puppy Linux) by putting it on a USB drive (FAT32 format). When I first copy the file from my desktop to the USB drive, the MD5SUM remains the same. I then unmount the USB drive from the desktop and mount it on the laptop. However, I now find that the MD5SUM of the file on the USB drive is now different from the original MD5SUM. And when I unmount the USB drive from the laptop and remount it to the desktop, the MD5SUM doesn't change back.
What exactly causes the MD5SUM of a file to change?
What kind of file is it. How long is it? How did you copy it?
If the file is over 2 GB, it was truncated. Fat32 isn't a good medium to transfer files if ownership and permissions need to be preserved. These permissions won't effect the md5sum however. If it was a sparse file, the copy could have had zeroes filling in the gaps. If the fat32 filesystem is mounted with the "conv=auto" or "conv=text" option, you could have had newlines converted to cl-lf's.
The most likely answer is that the file was corrupted.
What kind of file is it. How long is it? How did you copy it?
If the file is over 2 GB, it was truncated. Fat32 isn't a good medium to transfer files if ownership and permissions need to be preserved. These permissions won't effect the md5sum however. If it was a sparse file, the copy could have had zeroes filling in the gaps. If the fat32 filesystem is mounted with the "conv=auto" or "conv=text" option, you could have had newlines converted to cl-lf's.
The most likely answer is that the file was corrupted.
The file is an ISO file around 650 MB in size (Debian ISO). I used the GUI copy command in Puppy Linux.
There are only two reasons a file can change. One is there is some damage and the other could be how the system stored the file. In this case it should not have changed.
Might try to zip or otherwise store the file.
See the cp man page
"--sparse=WHEN
A `sparse file' contains `holes' - sequences of zero bytes that do not occupy any physical disk blocks; the `read' system call reads these as zeroes. This can both save considerable disk space and increase speed, since many binary files contain lots of consecutive zero bytes. By default, cp detects holes in input source files via a crude heuristic and makes the corresponding output file sparse as well. "
There are only two reasons a file can change. One is there is some damage and the other could be how the system stored the file. In this case it should not have changed.
Might try to zip or otherwise store the file.
See the cp man page
"--sparse=WHEN
A `sparse file' contains `holes' - sequences of zero bytes that do not occupy any physical disk blocks; the `read' system call reads these as zeroes. This can both save considerable disk space and increase speed, since many binary files contain lots of consecutive zero bytes. By default, cp detects holes in input source files via a crude heuristic and makes the corresponding output file sparse as well. "
So how do I preserve the MD5SUM value of a file as I transfer it from one computer to another through a USB drive?
How did you calculate the md5sum? Did both use the `md5sum' command? Run the command on the source file and the copied file using the `md5sum' command. Look at "ls -l <filename>" on both. Did one get truncated?
For an ISO file, the permissions aren't important and you won't run into a problem with fat32's. It isn't a sparse file so that isn't the problem.
I don't think that using the 'cp' command or fat32 will result in padding the file.
If you calculated the md5sum in a CD burner program (like K3b), It might be possible that the actual file has some padding at the end, beyond what is part of the ISO filesystem, and that the burner program only includes the bytes that are part of the filesystem.
I doubt that two versions of gnu's md5sum would produce different results unless the files are different. They should comply with RFC 1321.
Use the "cmp" which does a byte by byte comparison. Compare the original with the pendrive copy. Compare the pendrive copy with the copy on the second computer.
When you mount the fat32 partition on your laptop, make sure that the mount options on both systems match, i.e, issue the "mount" command and note the arguments. Most important here, is the length of the filename itself could be subject to change based on the fat32 mount option, "shortname=mixed".
When you mount the fat32 partition on your laptop, make sure that the mount options on both systems match, i.e, issue the "mount" command and note the arguments. Most important here, is the length of the filename itself could be subject to change based on the fat32 mount option, "shortname=mixed".
Thanks, Forrest Coredump. The length of the filename was the issue. The MD5SUM value was preserved in the transfer when I shortened the filename.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.