GNOME Bugzilla – Bug 692552
Error setting extended attribute 'security.selinux': Operation not supported
Last modified: 2016-12-09 15:37:56 UTC
evince 3.6.1 / poppler/cairo (0.20.2), on stock Fedora 18. If I try to save a PDF (using the "Save As" function) to my fileserver, this error is displayed: The file could not be saved as “file:///fileserver2/home/mjc/SHI-12061”. Error setting extended attribute 'security.selinux': Operation not supported Despite the error message, the file is successfully saved. My fileserver is a fuse-based moosefs (http://www.moosefs.org) system that does not support extended attributes. This worked fine in Fedora 17 / evince 3.4.0. So, basically, evince works, but it reports an error saying the save failed, which it did not.
Created attachment 285025 [details] [review] EvJobSave: Be more accurate when an error occurs We could at least say that setting of an attribute failed instead of saying that the save failed. This is implemented by the attached patch. (see also https://bugzilla.redhat.com/show_bug.cgi?id=1022649)
Review of attachment 285025 [details] [review]: ::: shell/ev-window.c @@ +2827,3 @@ { + GError *error = NULL; + gchar *filename; These are only used inside the if, so they could be moved there. @@ +2835,3 @@ + g_file_test (filename, G_FILE_TEST_EXISTS)) { + ev_window_error_message (window, job->error, + _("Attributes of the file “%s” could not be set."), How do you know that the error was because of the attributes? I find this message more confusing since it doesn't say anything about the save. I guess it should be say something like: Error saving document as %: attributes could not be set, or something similar. And if it's not a something interesting for the user, and the files was saved anyway, let's ue a g_warning instead of bothering the user with a cryptic error message :-P @@ +2838,3 @@ + EV_JOB_SAVE (job)->uri); + } + else { Move the else to the previous line. @@ +2846,3 @@ + g_free (filename); + if (error != NULL) + g_error_free (error); This error looks unused.
Is bug 736372 a dup?
Any chance to get some progress here?
I experience the same problem on F22 when I open a PDF coming from firefox with evince 3.16.1.
(In reply to Carlos Garcia Campos from comment #2) > Review of attachment 285025 [details] [review] [review]: > @@ +2835,3 @@ > + g_file_test (filename, G_FILE_TEST_EXISTS)) { > + ev_window_error_message (window, job->error, > + _("Attributes of the file “%s” could not be set."), > > How do you know that the error was because of the attributes? I find this > message more confusing since it doesn't say anything about the save. I guess > it should be say something like: Error saving document as %: attributes > could not be set, or something similar. And if it's not a something > interesting for the user, and the files was saved anyway, let's ue a > g_warning instead of bothering the user with a cryptic error message :-P You are right, I can not know that the error is because of the attribute (I would need to parse the error message for that). Maybe something more general would be more appropriate, like "There was an error during saving document to %s.". The specific error is on the second line. I can not even know whether the file was actually saved even if the new file exists because it can be an old file for which we don't have write permission.
It would be also handy to have another GFileCopyFlags flag. Something like G_FILE_COPY_ALL_APPLICABLE_METADATA which would copy only those attributes which are applicable to the destination file system.
Created attachment 341671 [details] [review] why not just ignore the inability to copy metadata that's what nautilus does, i.e. metadata is nice to have, but if it didn't copy don't report it
Comment on attachment 341671 [details] [review] why not just ignore the inability to copy metadata Ok, it makes sense. Thanks.