Encoding issue for hashfiles using “--enable_hashfiles” option about b2_fuse

[falense]

This is a separate error and as such should have a new issue.

I think the problem here is encoding. There is at least a handful of ways to encode something as simple as a text file from ASCII to UTF-8. This would be a fairly simple fix if I knew what encoding would be most versatile, right now I am just using a simple python string representation which I think is based on ASCII and "\n" for newline. If you have input on what binary representation that would be best please let me know.

[falense]

Also as for why some programs will be unable to open the file. A lot of GUI editors will do several rounds of READ, FLUSH and maybe even WRITE to a file even though you are not actually modifying anything. These files do inherently not support neither WRITE nor FLUSH. As such if your application tries either of these there will be problems. This feature was meant as a way to expose a bit more of the underlying features that B2 provides in case someone wanted to make a high level synchronization application on top of B2Fuse. As such I do not think it makes sense to make support for GUI editors (beyond the most basic like nano) a priority.

[Fibroblasto]

I think the problem here is encoding. There is at least a handful of ways to encode something as simple as a text file from ASCII to UTF-8. This would be a fairly simple fix if I knew what encoding would be most versatile, right now I am just using a simple python string representation which I think is based on ASCII and "\n" for newline. If you have input on what binary representation that would be best please let me know.

I am not sure at all, but UTF-8 looks to me like the most widely used encoding.

Also as for why some programs will be unable to open the file. A lot of GUI editors will do several rounds of READ, FLUSH and maybe even WRITE to a file even though you are not actually modifying anything. These files do inherently not support neither WRITE nor FLUSH. As such if your application tries either of these there will be problems. This feature was meant as a way to expose a bit more of the underlying features that B2 provides in case someone wanted to make a high level synchronization application on top of B2Fuse. As such I do not think it makes sense to make support for GUI editors (beyond the most basic like nano) a priority.

I agree with that. The kate editor, for example, makes a temporary file when opening and when saving it deletes the original file and gives the temporary file the original name, making it unsuitable to edit hardlinked files; quite an unpleasant behaviour! The above mentioned geany editor doesn't have that problem (no problems with hardlinked files), and it had the most consistent behaviour: it used the wrong encoding. But isn't it extrange the aparently random behaviour with nano I described above? Is nano what you would call a GUI editor? Anyway, these files are not intended to be edited, just to be viewed, and it is not worth the effort to adapt them to GUI editors IMO.

[falense]

Yes, the nano behaviour is indeed very weird. No, I would not classify nano as a GUI editor. I tried nano myself and found out how to trigger the “^@”. For each attempt open a new console and access one of these ".sha1" files. The first time a file is accessed (and only the first) this oddity happens. I have no clue as to why.

[Fibroblasto]

In my case, opening nano from Dolphin file manager it appears random-like. But that means opening a new console each time I use nano.

[falense]

I am not sure how to proceed with this issue. Should I add it to the known issues list and close the issue? If I had a fix that worked across many or all editors that would be the first choice, but I am not sure if such a fix exists.

[Fibroblasto]

As “cat” command works fine (which is actually the case) I would not bother with this very minor issue. It is not worth spending more time with it.

Perhaps, as a future enhancement, it would be good that the content of .sha1 file had the same format as the sha1sum.txt generated by Kleopatra program:
<hash_sum_of_the_file> <full_path_of_the_file>
But this would be a very low priority enhancement IMO.

Yes, perhaps it is a good idea to close this and leave it as a minor known issue.

[falense]

Is there are a reason why it should be the same format as sha1sum? Does it simplify something?

I can easily (one line fix) include the name of the file in the content. Changing the name of the hash file will require significant changes though.

[Fibroblasto]

Just for a more easy way to compare and verify that everything is OK. A user script or third party program might more easily check that the output of sha1sum and the content of the .sha1 file are exactly the same in a more easy way. But that is not important at all; that comparison can already be made betwen the first 40 characters of sha1sum output and the “cat“ command output of .sha1 file. You might forget about this.

[falense]

Alright. Lets keep it as it is then. Thanks for the feedback, adding this to known issues and closing.