First, to answer your question about the sha1. The blocks’ file names are created from the sha1 hash of that block. This way when adding new data it’s easy to chop the file up, to get the block(s), hash the block, and then either write it to the disk, or just throw it away because a file with that name already exists (since that should be a block with the same content). If a file is edited, the changed parts will become new blocks, the block files should never be edited, just added and removed.
So we can use this in reverse to see if a file’s contents have changed. If even one bit in the file is different, the hash should be different (and generally should be wildly different, not just a tiny bit different). So “sha1sum ff/*” ran sha1sum and asked it to calculate the sha1sum (hash) of every file in the ff/ directory. The results of that look like:
ff005940f6242423790d281be6c553a643d1b182 ff/005940f6242423790d281be6c553a643d1b182
ff057ace37bd62dc3794172d21749fba9d97a702 ff/057ace37bd62dc3794172d21749fba9d97a702
You should see the file name and the hash matching (except for the first 2 characters which come from the directory name). So if they don’t match, that file’s contents have changed since it was first uploaded to seafile. I was trying to suggest that you pick a couple of samples and just compare by eye, like all of 01/* and ff/* and if the last 8 characters match, then the file is probably fine, but if they don’t match that file is broken. If none match, then it’s probably already a lost cause.
That file you have seems weird to me. My files in fs/ contain no readable text at all. But that gave me a clue that lead to someone else’s work along these lines. https://awant.medium.com/seafile-data-structure-c8a1e62a64e4
And that lead to a long ramble that isn’t going to be practical to you. Feel free to skip to the next post for the practical plan B (or is it C?).
According to that site, the files in fs/ are all compressed with zlib (explaining why I mine don’t have any readable text). It seems that isn’t true of your files, so I suspect that the windows agent doesn’t do zlib for some reason.
With a bit of python I was able to decompress some, and they look like reported in that blog. Some are the “dirents” files like you quoted, that seem to be a directory (a list of files and sub-directories). Files have a size number, other directories don’t. The id is the name of another file in the “fs/” directory with the / missing (so “id”: “713c4175bb8ab07ac7b006d159aaa7e7af8aa90f”, points to file 71/3c4175bb8ab07ac7b006d159aaa7e7af8aa90f ).
The other kind of file in fs/ doesn’t have the “dirents” string, and looks like this:
{
"block_ids": [
"0b750676df87beacf1e42a3e3e33ecbdcc98ac0d",
"6633a66e9e2fb14cde76177173430af23e9bd325",
"a3352a4ef431be9a031f5fc598da5fa8d522fb17",
"629f832541e6f61a1047eee4da0f27de56b6b961"
],
"size": 4622322,
"type": 1,
"version": 1
}
That lists the 4 blocks from the blocks dir (again, need to add the / after the second character), that have to be read in order to make the original file. Since you don’t have any of these, we don’t know the connection between the filename and the block(s) for that file.