I’m pushing changes from one local repository to another. I keep my channels in-step, so the channel name in the source repo and the channel name in the target repo are the same - so I should simply be pushing those changes that are new in the source repo.

So this has worked previously:

$ pijul push --all  --from-channel  ChannelAlpha  --to-channel ChannelAlpha  /path/to/destination/repo

but this does not:

$ pijul push --all  --from-channel  ChannelBeta  --to-channel ChannelBeta  /path/to/destination/repo

Uploading changes [==================================================] 130/130                           
Error: No such file or directory (os error 2)

Not sure what other info I could provide here off the bat. First thing is that a more descriptive error would be helpful. I think also if pijul had a verbose flag, that would help with reporting issues. But if there’s an idea as to what the forwarded error from the OS amounts to, I’ll try and provide what details I can.

Thanks

Interestingly, my target repo seems to have a lot of files with (the change hash?) appended to the filename:

drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.2GOTRC2IRWLPI/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.2IP6G275R3RHQ/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.2SJKJ7TLOCNZ2/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.2WN4DQZ65RR36/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.34DWD6POSZCTE/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.36STZXUTMUA5O/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.4I7KHRIVBZSIW/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.4KKZP2NDQKWRE/
drwxrwxr-x   2 user user 4.0K Oct 27 17:55  MyFiles.4WI27WPIBYJPG/

Can not repeat pijul push issue. Please provide clearer steps.

Afraid I don’t really know what I can do to provide a better MRE, which is itself part of the problem for me - I’ve just tried to pijul unrecord a change, because I ended up adding a line after I had recorded that change, and wanted to tack that back on. I get the same error (different context of course) - but just a bare no such file or directory. Without knowing what file it’s looking for, where in the code these OS errors are cropping up, etc., it’s almost impossible to be able to work out the cause of the issue, without just zipping up my repo and sending it up here for someone to have a look at (which I’m afraid I can’t really do even if that were an option).

I am just getting sporadic messages like these when doing everyday work in my repo, so I’d suggest to start with that any points messages like this are caught and forwarded to stderr, those lines probably could do with being looked at, and having more detailed error messages relevant to the context output at that point. Of course if something like that can be achieved, then I’ll more than happily revisits the specific situations and try to provide a minimal example, but until then I’m afraid I haven’t a clue what is going on.

I’m new to pijul, don’t have much knowledge of its internals, and also haven’t worked in Rust before. So I don’t know if I can be much help in terms or trying to add contextual errors onto where this is happening.

However, I think I’d be happy having a go with submitting a change that at least prints out the name of the file or directory it was looking for. For me that’s a must in terms of error reporting anyway, I’ve had the same in some code at work, and if it’s a file-based exception it’s useless unless I know what the file is. So I’d happily give that a go if I can find time and attach a change here. It’d be a good exercise at least. Then folks would be free with where they want to take anything from there, but hopefully it would help with diagnosing future errors relating to similar messages - I’ve seen it crop up in several contexts so far.

Would you believe those two lines took about three hours? :p

I’m sure it could be improved, but I’m not finding rust’s syntax the most self-explanatory. I’ve only implemented this one case in the end as that took long enough.

It seems that at least one cause for the error is that it’s unable to open a global config file. $HOME/.config/pijul does exist on this machine. config.toml under this directory didn’t. I’ve just created it, now I get an error that it can’t be read - not sure what keys it is expecting to be present a minimum, I’ve tried a couple. Adding the author section was sufficient.

Seems an issue that it should need one for some operations (unrecord) but not others (record), but in any case, maybe that’s something that needs looking at - i.e. expanding on error reporting in the area included in the patch.

Setting up the minimally-required keys in the config TOML seems to be enough to get my original usecase working again!

Hi! The error story for Pijul should definitely be improved. I don’t want to apply your two patches just yet, since a more general way would be to get rid of anyhow altogether and provide more systematic contexts for errors.

If you’re interested in helping, I can help you get started.