After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 330932 - File open dialog message misleading for files with no read access.
File open dialog message misleading for files with no read access.
Status: VERIFIED DUPLICATE of bug 351351
Product: GnuCash
Classification: Other
Component: General
1.9.x
Other Linux
: Normal normal
: ---
Assigned To: Chris Lyttle
Chris Lyttle
Depends on:
Blocks:
 
 
Reported: 2006-02-12 23:09 UTC by Aaron Larson
Modified: 2018-06-29 20:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Aaron Larson 2006-02-12 23:09:59 UTC 
When opening a file that the user doesn't have read access to, the
error dialog is a bit cryptic:

  The file type of file <FILENAME> is unknown.

This may be misleading to the user.  The message should indicate a permission problem.

This was discussed in the following email thread:

https://lists.gnucash.org/pipermail/gnucash-devel/2006-February/016348.html
Comment 1 Aaron Larson 2006-02-12 23:17:51 UTC 
Excerpts from the subsequent email discussion:

AL> Aaron Larson
NW> Neil Williams
DA> Derek Atkins

AL> ...When opening a file that the user doesn't have read access to,
AL> the error is a bit cryptic:

AL>   The file type of file <FILENAME> is unknown.

NW> I know how that happens - gnucash tries to identify the file by
NW> letting each backend try to open it in turn. If none can open it,
NW> it complains that it cannot understand which type of file it is
NW> meant to be. We can't use mimetypes to distinguish the forms (as
NW> two are text/xml and we've never enforced a mime-type on old
NW> files) so we do have to open the file to determine the type.

DA> Well, the other option is to actually pass the error up the stack
DA> so that the caller can get a GNC_BACKEND_ERR_FILE_INACCESSIBLE (or
DA> something like that) up the stack..  I've seen similar
DA> error-hiding as a result of qof_session_export() not passing the
DA> error up the stack.  :(

NW> But when trying to determine the type, all we know is if it is the
NW> correct type or not. In QSF, I'm implementing :

NW> f=fopen(path, "r");
NW> if(!f){ qof_backend_set_error(...);}
NW> fclose(f); 

NW> block that sets a new QofBackendError: ERR_FILEIO_READ_ERROR at
NW> the start of the file type check which I can also implement in
NW> gnucash. So at least then, if we can't open the file for reading,
NW> we can set a backend error and quit the load.
Comment 2 Christian Stimming 2006-09-12 14:05:01 UTC 

*** This bug has been marked as a duplicate of 351351 ***
Comment 3 John Ralls 2018-06-29 20:57:49 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=330932. Please update any external references or bookmarks.