unison -ui text does not report failure due to missing username unless batch=true

[gwemmie]

If this bug does not apply to anything newer than 2.51.2 (ocaml 4.09.1), then I apologize. Those are the newest versions of each that I was able to get simultaneously installed onto Arch Linux and Armbian.

I spent days wracking my brain trying to figure out why CLI unison would hang indefinitely and do nothing, immediately after supposedly successfully syncing props, with no error message. Almost a terabyte of new data, none of which was being transferred.

Finally just now I tried combining auto = true and force = <root> with batch = true which I could afford to do because the destination is currently just a mirrored backup. At first I was only using auto = true and force = <root>, not batch = true, but once I added batch = true, suddenly I was receiving actual error messages that allowed me to get to the bottom of the issue and finally transfer these files.

Those error messages were Failed: no user <username>. This is because my local source and remote destination machines do not have the same username on uid/gid 1000.

So the purpose of this bug report is to complain that I would have figured this out several days earlier if I was allowed to see those error messages without batch = true. I doubt this behavior was intended, and if it was, then I don't understand why.

I'd like to also mention, I don't think most people would expect unison to go by usernames rather than id numbers, when virtually any other program I've used that transfers files will only go by id numbers, so I feel like I got trapped there. It's partly my fault, because despite knowing most of the docs like the back of my hand I somehow completely missed numericids until someone mentioned it in a forum thread.

The reason I was doing this all in ui = text is because of #207. It's a huge initial sync job.

[gdt]

This seems like a valid bug. 2.51.2 is recent enough to be in the bugtracker; it's really 2.48 and earlier that are not being maintained.

I encourage you to read the sources to see if you can see how batch suppresses errors.

[tleedjarv]

I am unable to replicate this issue. Could you test with current git master and see if you still get the same result? Could you provide more details on your configuration, in addition to auto and force?

Additionally, do you think you can get a stack trace from the instance that hangs indefinitely?

[tleedjarv]

Feedback required. If you can reproduce the setup then please test with a current release.

[gdt]

30-day timer for recent repro started. As usual, even if closed and you can provide a repro recipie with the current release or master (master strongly preferred), please feel free to reopen or file a new issue.