XnView Software

XnView: MP 1.9.3 64-bit (Linux) - Libformat 7.226
(Installed with the .deb package)
OS: Ubuntu Linux 22.04.5 LTS (64bit)
Note: Affects all previous versions of XnView

Description:

XnView writes an excessive amount of irrelevant data to the `stdout` and thus automatically to the `$HOME/.xsession-errors` file (or in similar files that collect the `stdout` and `stderr`, such as `run.log` in LXDE, depending on the desktop system used). Instead, X client programs should write to `stdout` or `stderr` only relevant error messages or user-requested debugging or other levels of information, which is the way X clients are expected to behave. In a XnView session that lasts more than just a few minutes, if the user browse through many directories containing more than one thousand files each, XnView will generate an unmanageable amount of details of every single user input and every single read that XnView performs, as if it were permanently in a full debugging mode.

This creates a series of problems in the user's Linux system, which in some cases may be serious, especially when the session with XnView lasts several hours and most critical if the Linux system is left on for long time, (e.g. by suspending/hibernating the computer).

Some of the problems:
- Huge `.xsession-errors` (or equivalent log) file that can easily grow beyond tens of GB just with XnView trivial data (not errors).
- Equally huge amount of unnecessary writes to hard drive or SSD, that worns them out, and slow the system.
- Hijacks the `.xsession-errors` (or equivalent file) by filling it useless details and making the file nearly useless for troubleshooting errors of any other X client programs.
- Security breach: Leaking all the details to a written record of all the full path files and directories and actions performed by the user without their knowledge, which defeats any efforts of protecting user's privacy. For example, it is perfectly possible to get a full list of files, how many times any of them was accessed, copied, deleted, etc..

To reproduce:

Pre-requisites: A linux system with XnView installed, and availability of several directories (the more, the better to reproduce), with at least 2000 image files each (more is better for this experiment). You must use the originally installed launcher (XnView.desktop). If you have made any script or modifications to the launcher that makes any redirections of `stdout` or `stderr`, this demonstration will not work.

1. In the Linux system, rename (or as preferred, move, or delete) the `$HOME/.xsession-errors` (or equivalent) file.

2. Run XnView by double-clicking its original launcher icon.

3. Browse to any of the directories with big amount of pictures, and perform several operations on it, such as viewing many files full screen, select portions of the image and Save as..., copy and paste several files somewhere (e.g. in /tmp), make batch operations, etc.

4. Change directory to any of the other directories, and repeat the activities mentioned in (3).

5. Repeat steps (3) and (4) for at the very least 15 minutes. If you can extend the usage of XnView at this point for much longer, the results will be more impressive.

6. Close XnView, and review the size and the contents of `$HOME/.xsession-errors` file (or equivalent), The bigger the directories and the more you changed between directories, the file will be considerably bigger.

Actual behavior (bug):
The amount of data written to the `stdout` and thus automatically to the `.session-errors` (or equivalent) file by XnView is huge and entirely useless, even if someone would be doing some debugging: Most likely, there are no error messages, and if there would be, it would be hidden by tens of thousands of just trivial and repetitive output of every single mouse input by the user and countless repetitions all the filenames with their full path, that are present in all accessed directories. None of those are errors, thus they don't even belong to that file. In a ~12 minutes session, my `.xsession-errors` file was entirely filled with XnView output (not a single error): 91548 lines, which means almost 100000 read-writes to my old home hard drive, not justified. In sessions of several hours, I can see this file to grow beyond 10GB only from XnView, which means millions and millions of disk I/O without any justification, and a file which is absolutely unmanageable even by VIM.

Expected behavior:
In such a session, XnView should have only written any errors produced by the program, and in any case it should not include any other information that was not explicitly requested by the user with e.g. debugging, info, or warning levels flags. In this case, the `.xsession-errors` (or equivalent log) file should have almost no information from XnView, other than perhaps a few lines of very basic startup message.


Why this is not a "linux bug"
The `.xsession-errors` is a feature that Linux offers to applications developers, to be used wisely as a debugging log. The Xsession writes standard output and standard error to that file for all X clients, and that is how Linux is designed. In other Linux desktops, the mechanism may use a differently named log file (e.g. "run.log" in LXDE), but the issue is identical. This log file is expected to be used in the correct way, but that is the entire responsibility of the developers whom write X programs for Linux, to decide what they write to stdout/stderr and thus to the `.xsession-errors` (or equivalent) file. That obviously isn't users responsibility. If all hundreds of X programs in any Linux system would write everything to `stdout` all the time, it would be impossible to run such a machine for longer, and the hard drives or SSDs would be worned out faster than expected, plus the entire system would get slowed down by so many drive I/O activities. Therefore, users should report any misbehaving program to its developers.

Note that this problem has been already mentioned in 2019 this thread: https://newsgroup.xnview.com/viewtopic. ... rs#p154315 and also I happen to have mentioned by the end of that year in the middle of some post regarding another issue, which was more serious, but had been made worse by this problem. But in the first case (see the link), the issue was only discussed as some kind of a "Linux problem", and the approach by the members who participated in it, was to address it as something that should be handled the "Linux way", i.e. with one of the numerous bash trickery that would mask the real issue.

Unfortunately, while there are many ways a savvy Linux user can tweak their system to mitigate many issues, including this one, I must be very clear: This is NOT a "Linux bug", and no, please, don't make this the place to start discussing workarounds with bash file descriptors redirections, wrappers to launchers, `cron` entries, python scripts, etc. etc. . That would only mask the issue. If anyone is inclined to describe a workaround script, please create your own thread. This is a bug report and it is an important one. The last time such discussion was made, the issue was totally forgotten and it looked as it was somehow "solved", 6 years ago. Well, it wasn't.

It's 2025, it's time someone filed a bug report.

Please keep in mind that XnView is not a program for "Linux experts" or programmers: it's a program for users. Some people still think that anyone using Linux is some kind of a hacker that knows how to solve their computer problems or google them around, but that's more than 15 years obsolete and ...a bit juvenile idea .

I would like to share something that helped me, just as suggestions topics, that I gathered with the help of IA, (Google's Gemini and GPT-4), because it's not easy to find enough documentation on how to correctly use the Linux feature of logging `stdout` and `stderr` to certain files. This is just some ideas, I hope they might be interesting for the discussion.

This is formatted with standard markup, which won't be rendered in this forum, but which can be pasted somewhere else where it will be rendered correctly:

## Best Practices for Using .xsession-errors in Linux Development

When developing applications that run in a Linux environment, especially those that utilize the X Window System, it's essential to handle output to the `.xsession-errors` file responsibly. Here are some best practices for developers to consider:

### 1. **Limit Output to Necessary Information**
- **Use Logging Levels**: Implement logging levels (e.g., DEBUG, INFO, WARN, ERROR) to control what gets printed to stdout and stderr. Only log essential information at the appropriate levels.
- **Conditional Logging**: Allow users to enable or disable verbose logging through configuration options, so they can choose to see more detailed output only when needed.

### 2. **Use Dedicated Logging Libraries**
- **Logging Frameworks**: Utilize established logging libraries (like `log4j` for Java, `logging` for Python, or similar) that provide more control over logging output, including the ability to direct logs to files instead of stdout/stderr.

### 3. **Avoid Printing Large Data Structures**
- **Summarize Data**: Instead of printing entire data structures or large objects, provide summaries or key information that can help in debugging without overwhelming the log file.

### 4. **Handle Errors Gracefully**
- **Error Reporting**: Use structured error reporting instead of dumping stack traces or raw error messages to stdout. This can help keep the output clean and focused on actionable information.

### 5. **Use Environment Variables for Debugging**
- **Debug Flags**: Implement environment variables that can toggle debugging output without changing the code. This allows users to enable detailed logging only when necessary.

### 6. **Document Output Behavior**
- **User Documentation**: Clearly document what information will be logged and under what circumstances. This helps users understand what to expect and how to manage their `.xsession-errors` file.

### 7. **Regular Maintenance**
- **Log Rotation**: Encourage users to implement log rotation for `.xsession-errors` to prevent it from growing indefinitely. This can be done using tools like `logrotate`.

### 8. **Test Output in Different Environments**
- **Cross-Platform Testing**: Test how your application behaves in different environments and configurations to ensure that logging does not become excessive or unmanageable.

### Documentation and Resources
While there may not be a single comprehensive document specifically addressing `.xsession-errors`, the following resources can provide guidance on logging best practices in general:

- **Linux Programming Guidelines**: Many Linux programming books and online resources cover best practices for logging and error handling.
- **Specific Language Documentation**: Check the documentation for the programming language you are using, as they often have sections dedicated to logging practices.
- **Open Source Projects**: Reviewing the logging practices of well-maintained open-source projects can provide insights into effective strategies.

By following these best practices, developers can ensure that their applications contribute positively to the `.xsession-errors` file, making it a useful tool for debugging rather than a source of clutter.

right, i'll change the way to show logs...