Thoughts on update mode and check mode

[ghost]

Never seen rhash before, seems pretty nifty. I've used mtree from FreeBSD which is similar, more geared towards filesystem correctness than simple checksums.

Couple thoughts:

Might be nice to have a mode for using -c hash-file with recursive lists, to error if files are present which are not listed.

For update mode, if mtime and size were saved, rhash could behave like rsync and update files that had changes to mtime and/or size, rather than ignoring them.

I can elaborate more if you're curious, but also completely understand if you have no interest. I guess my idea on update would make the traditional update behavior more like a -a/--append by comparison.

Anyway, thanks for writing the tool. I'm evaluating it to see if I can use it in place of mtree for certain things.

[rhash]

Might be nice to have a mode for using -c hash-file with recursive lists, to error if files are present which are not listed.

Nice idea

For update mode, if mtime and size were saved, rhash could behave like rsync and update files that had changes to mtime and/or size, rather than ignoring them.

Currently 4 of the supported by RHash formats can store file size: SFV, torrent files, ed2k-links and magnet links, while only SFV stores mtime in its comments. I consider SFV format and ed2k-links obsolete and do not intend to develop their processing any further. Torrent files format is bad because of its info-hash, which depends on block-size extra parameters, so it's support is also frozen. Magnet links format without mtime parameter doesn't fit for rsync alternative.

So it should be some specific format, may be based on JSON. I don't know any existing good format fit for this purpose. Such rsync-like program should be written as a python script using librhash python bindings, since supporting new formats and rsync behavior is not a simple task, and python development is much faster than writing in C.

[jake7301]

As a follow up to this idea, I would also love it if mtime was stored. I use rhash as a way to detect bitrot. If mtime was stored then there are two things that can be done with mtime.

1. When running check, mtime can be checked first. If not equal the file can be skipped.
2. When running update, any entry with a not-equal mtime can be rehashed

Currently, I don’t have a good way of dealing with files that have changed. I currently have to sort through the list of failed check sums manually to determine if it’s truly a failed check sum, or just a changed file.

If I have several changed files I don’t have a good way of updating them. Currently, I just delete the whole file and recalculate it.

I think using mtime would help us deal with changed files.

[rhash]

The first idea "to error if files are present which are not listed" is now discussed in the issue:
#198 options to list missing and/or unverified files.

For the second Idea (to store mtime and size and to respect it on verification), there is a curtain demand for this feature (#107, #185), since the use case for it is evident.

As I said earlier in the discussion, such feature will require development of a new hash-file format. So it is a big feature.

One problem is, that filesystem usually stores file modification time as a local time. It depends on the current timezone. Even when a summer/winter time changes, the modification time of each file also is shifted by 1 hour. So such time will differ from the time previously stored into a hash file.