|Anonymous | Login | Signup for a new account||2018-09-22 11:30 UTC|
|My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003453||Doomseeker||[All Projects] Suggestion||public||2018-08-20 22:24||2018-09-18 12:33|
|Assigned To||Pol M|
|Target Version||1.2||Fixed in Version||1.2|
|Summary||0003453: When Doomseeker fails to startup due to file system errors, return errno/message from the filesystem|
|Description||0003396 is supposed to fix a possible lack of any indication what went wrong during startup (e.g. when a config directory cannot be read), but it doesn't give a precise reason why something failed, such as "other unexpected cases" as indicated in code. In such "other unexpected cases", the error message will still be hopelessly useless.|
Using errno.h and returning that message in the dialog would be a mostly foolproof way to solve the problem for good.
Pol M (developer)
|new pull request regarding this issue:https://bitbucket.org/Doomseeker/doomseeker/pull-requests/16/adresses-0003453/diff [^]|
I merged Pol M's pull request and also pushed follow-up commits:
1. Already produce DirErrno structures at the moment when directories fail to be created instead of doing this by performing subsequent checks after "something unspecified" fails.
2. When data directories fail to be created due to lack of permissions, try to figure out which parent directory is the one that lacks these permissions. This will also check NTFS permissions.
To summarize, the current behavior is this: Doomseeker attempts to create several storage directories that it "needs" to run. These directories include places to store demos, master server cache, configuration and "generic data". Doomseeker upon launch will try to create as many of these directories as possible. Each failure to create a directory is collected on a list with an according errno value and strerror message. In some cases, like when user doesn't have NTFS permissions, it is possible that a failure will occur but errno value will stay at zero. Doomseeker will try to do some extra permission checks to produce a custom error with custom message, explaining which directory is the one that lacks permissions. If this fallback operation still fails to deduce the error reason, Doomseeker will resign to a generic "cannot create directory" error message. Doomseeker will pop up a message box to display all errors that it accumulated, discarding multiple errors for the same directory, and then it will quit. If no errors occur, Doomseeker continues its run.
Two side notes regarding this behavior:
1. When you think about it, lack of access to storage space is not really "critical" and it's questionable that Doomseeker quits if storage space cannot be created. However, it was assumed that most users will want their files saved, so having a hard, crashing failure in the end is more beneficial to the user than just popping up a box that the user may ignore or even avoiding a message box altogether and only quietly logging the errors to the log and then continuing "normal" operation while user unknowingly loses data.
2. Another thing about directory permissions is that Doomseeker will only complain if it cannot create the storage space. If, for example, you take away permissions to the already existing "demos" directory, this case won't be checked. Odd behavior will, however, ensue - demos won't record, and the demo manager will show empty playlist.
edited on: 2018-09-18 12:33
I will assume this is fixed, at least as I tried on GNU/Linux (ext4 filesystem), Doomseeker 1.2~beta-180915-0824. I didn't bother testing NTFS permissions, but if it's not resolved then a new ticket can be opened – or this ticket reopened.
Thanks to both of you.
Quote from Zalewa
You have a nice teacher. 😊
Quote from Zalewa
Please file a ticket for this if needed; even if the resolution would be something else than "resolved".
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
|Supporters:||No one explicitly supports this issue yet.|
|Opponents:||No one explicitly opposes this issue yet.|
|2018-08-20 22:24||WubTheCaptain||New Issue|
|2018-08-20 22:24||WubTheCaptain||Relationship added||related to 0003396|
|2018-08-20 22:25||WubTheCaptain||Severity||minor => tweak|
|2018-08-27 03:06||WubTheCaptain||Relationship added||child of 0003279|
|2018-08-28 03:56||WubTheCaptain||Description Updated||View Revisions|
|2018-09-03 01:05||Pol M||Assigned To||=> Pol M|
|2018-09-03 01:05||Pol M||Status||new => assigned|
|2018-09-03 23:13||Pol M||Note Added: 0019488|
|2018-09-03 23:14||Pol M||Status||assigned => needs review|
|2018-09-05 21:58||Zalewa||Note Added: 0019493|
|2018-09-05 21:58||Zalewa||Status||needs review => needs testing|
|2018-09-18 12:32||WubTheCaptain||Note Added: 0019542|
|2018-09-18 12:32||WubTheCaptain||Status||needs testing => resolved|
|2018-09-18 12:32||WubTheCaptain||Fixed in Version||=> 1.2|
|2018-09-18 12:32||WubTheCaptain||Resolution||open => fixed|
|2018-09-18 12:33||WubTheCaptain||Note Edited: 0019542||View Revisions|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2018 MantisBT Team|