Hrm, the only difference that seems to make is that it puts a "*" by the filename:

$ sha1sum Fedora-9-Nathan-i686.iso
3a505e21181f41d749877266ab9948af88792497 Fedora-9-Nathan-i686.iso

$ sha1sum -b Fedora-9-Nathan-i686.iso
3a505e21181f41d749877266ab9948af88792497 *Fedora-9-Nathan-i686.iso

Is that really the only difference? Why in gods name is the windows sha1sum library using the text around the name of the file to determine how to open, that shoudl be done by looking at the file itself and figuring out what it is.

I'm not really inclined to change this, I'd file a bug against the windows sha1sum software.

Sorry for not replying in time, but I still consider this to be an issue, so I'm reopening it.

I probably didn't explain clear enough. First of all, the sha1sum I'm using on Windows is the usual GNU sha1sum from Coreutils, compiled on MinGW.

You're right that on Linux the only difference between text-mode and binary-mode summing is the asterisk in the output (because text mode = binary on Unix systems). However, when the asterisk is not there it means "verify this using text mode", and while Linux doesn't care, on Windows text mode is something quite different (e.g. \r\n gets converted to \n), so the resulting sum is different, so the check fails.

These are the sums (calculated on Windows) for the F9 DVD, for reference:

sha1sum -t Fedora-9-i386-DVD.iso
c913868d589174657aacbd48d5cbe926fc269041 Fedora-9-i386-DVD.iso
sha1sum -b Fedora-9-i386-DVD.iso
50253a35b5ba128c9a57b2a10cbd829813fc5119 *Fedora-9-i386-DVD.iso

Oh, and it's not a sha1sum bug, it's operating exactly as docs say.

I updated the pungi source code to produce binary sha1sum files.

I updated the pungi source code to produce binary sha1sum files.

Doesn't appear so. {{{pungi/src/pypungi/init.py}}}, line 929:

{{{ sha1file.write("%s %s\n" % (sha1sum, os.path.basename(path)))}}}

No asterisk means text.

http://git.fedorahosted.org/git/?p=pungi.git;a=blob;f=src/pypungi/util.py#l91

We open the file in binary mode so that the hash returned by the sum generator should have a *, I'll verify the output in my next test compose.

We open the file in binary mode so that the hash returned by the sum generator should have a *.

How is that relevant? Since we feed hashlib the strings, not the file itself, it has no idea about modes. However, we output the digest as "hash<space><space>filename", which means "text mode hash". Binary is "hash<space><asterisk>filename".