Description of problem: Let say that as a result of older choices of scan locations in ~/.sane/xsane/xsane.rc we have recorded: "working-directory" "/home/<user>/a/b/c" and now we are trying to write new scans to a directory /home/<user>/x/y and all directories in question do exist. So we start a location choser in xsane window and with a help of file browser we change a target file name to, say, "<user>/x/y/page_0001.jpg". That is how it comes up (if it does - see below) when doing that in a "natural" way. The problem with this is that "working-directory" does not change and page_0001.jpg will end up there and not /home/<user>/x/y. This can be observed also after quitting xsane and lookin into ~/.sane/xsane/xsane.rc. Corresponding entries in it will read: "working-directory" "/home/<user>/a/b/c" "filename" "<user>/x/y/page_0001.jpg" and only basename from "filename" is clearly used. Even without quitting xsane if you will try to modify a target a file browser will stubbornly open on an old "working-directory". Removing from ~/.sane/xsane/xsane.rc a specification of working-directory altogether will result after the next quit in the following in xsane.rc: "working-directory" "/home/<user>" and again there is no good way to change that save of bringing xsane.rc into an editor and rewriting it. A modification in xsane window of a chosen target to, say: ~<user>/x/y/page_0001.jpg does not have any effect at all. OTOH replacing that with /home/<user>/x/y/page_0001.jpg _may_ have that effect that this and subseqent pages will be saved in /home/<user>/x/y/. Even if that will do happen a setting for "working-directory" does not change. An operative word above is "may". It seems to be a pretty random if a save location change will happen or not. Similarly picks in a file browser appear to have a rather loose connection with what shows up in a save target field of xsane. Sometimes they "take" and sometimes do not. Easy to observe after erasing everything from that field and trying to fill it back using browsing. A barrel of fun. Direct typing looks like having desired effects. All of the above apparently courtesy of upgrading distro from F11 to F13. Version-Release number of selected component (if applicable): xsane-0.997-10.fc13 How reproducible: always
I've only found one active piece of code where the working directory preference is set: ... if (!preferences.working_directory) { char filename[PATH_MAX]; if (getcwd(filename, sizeof(filename))) { preferences.working_directory = strdup(filename); /* set current working directory */ } } else { chdir(preferences.working_directory); /* set working directory */ } ... FWIW, there is code implementing a menu entry "Change directory", but it has been commented out by upstream between versions 0.991 and 0.993 (that's what we had in FC-7), but I think this was removed purposefully: I looked at the code and it seems to me that it simply sets the directory from the filename, but only if that filename is absolute. If it's relative (e.g. the default "out.pnm", it does nothing. I checked this by typing in a filename with and without an absolute path (e.g. "/tmp/out.pnm" vs. "out.pnm"), then clicked on the button besides the filename text entry which brings up the file selection dialog. With an absolute file, it would set the directory from it, with a relative filename, it would put you in the (once set never changed) working_directory from the preferences. Please try it out and check if you can confirm this. Thanks.
(In reply to comment #1) > With an absolute file, it would set the directory from it, with a > relative filename, it would put you in the (once set never changed) > working_directory from the preferences. That is correct (and I thought that I wrote that more or less but maybe I was not clear). Still the problems are as follows: 1) working_directory is honoured but requires an editor to set 2) something will set, to $HOME, and record working_directory if absent from xsane.rc 3) there is no obvious way to change a location of a scan targets (extra "fun" if you are scanning multiple pages with an autoincrementing counter) 4) using a file browser sets, maybe, a relative path _only_ and scans end up in unexpected places; in particular not where you would expect them to show when you are reading what is possibly spelled out on your screen (usually only a fragment of a path is visible so no way to tell at a glance if this is relative or absolute) 5) ... moreover results of using a file browser are unpredictable and using it may, or may not, have any effects on scan displayed and/or used filenames (I could not figure out why and when this sometimes works, to an extent, and other times appears to be totally ignored - possibly another bug on its own) 6) the only somewhat sane way to have a control over scan target names is to type explicititely absolute file names in a location field of xsane 7) all of this is a regression relative to what worked in the past Point 6) gives a workaround of sorts but a "principle of the least surprise" is violated many times over. Fighting with these file names drove my wife up against the wall and she is a rather smart person even if computers are not her field.
Thinking about this for a bit more - regardless of working_directory vagaries IF setting file names via a file browser would work reliably AND if one would always end up with absolute path names then results could possibly be acceptable; without any other changes in xsane code.
(In reply to comment #2) > Still the problems are as follows: > > 1) working_directory is honoured but requires an editor to set > 2) something will set, to $HOME, and record working_directory if absent from > xsane.rc My impression (from looking at the code) is that working_directory is/was the "old way" of doing things and upstream is (or was) in the course of changing this to a concept of "last used directory". > 3) there is no obvious way to change a location of a scan targets (extra "fun" > if you are scanning multiple pages with an autoincrementing counter) > 4) using a file browser sets, maybe, a relative path _only_ and scans end up in > unexpected places; in particular not where you would expect them to show when > you are reading what is possibly spelled out on your screen (usually only a > fragment of a path is visible so no way to tell at a glance if this is relative > or absolute) > 5) ... moreover results of using a file browser are unpredictable and using it > may, or may not, have any effects on scan displayed and/or used filenames (I > could not figure out why and when this sometimes works, to an extent, and other > times appears to be totally ignored - possibly another bug on its own) By "using a file browser", do you mean the file chooser dialog in the application? > 6) the only somewhat sane way to have a control over scan target names is to > type explicititely absolute file names in a location field of xsane > 7) all of this is a regression relative to what worked in the past Well, please describe to me how it behaved before it "regressed", if that is the desired behavior... > Point 6) gives a workaround of sorts but a "principle of the least surprise" is > violated many times over. ...with this information I can look into making it behave better.
(In reply to comment #4) > (In reply to comment #2) > > 2) something will set, to $HOME, and record working_directory if absent from > > xsane.rc > > My impression (from looking at the code) is that working_directory is/was the > "old way" of doing things I am convinced that you are correct as I did not try to go through the code. Only in this case why to bother set it, in some cases, and follow it? > > 5) ... moreover results of using a file browser are unpredictable > By "using a file browser", do you mean the file chooser dialog in the > application? Yes. Whatever is the name. That thing which pops out if you click on a "storage" ("diskette") button left of a location field on an xsane GUI. > Well, please describe to me how it behaved before it "regressed", I thought that I did. It was possible to set a target location for scans by using methods implied (or suggested, if you prefer) by an xsane interface. After upgrading to F13 it appears that for that one has to type absolute file names in a corresponding field. Relative are not good enough. Moreover results from the file chooser show up or not in a fashion I am unable to predict. I cannot check now if the last versions used in F11 were following "the last used directory", or some other means, but it worked. About this file chooser. While experimenting I cleared a location field. Whatever I was doing later in this chooser, possibly when it was not "in the mood", was resulting in blank file names and after quitting xsane I ended up in xsane.rc with these lines: "filename" "" At least consistent if not what I was trying to achieve. When the file chooser gets an attention then instead of what would have worked (expand this) $HOME/some/place/scan_0001.png I end up with $(basename $HOME)/some/place/scan_0001.png and the whole 'dirname' part gets quietly ignored. > if that is the desired behavior... Do you try to suggest that storing files in some unexpected place is something done on purpose?
You seem to imply that I'm arguing that it's somehow your fault that this doesn't work, but I'm rather just trying to find out what exact behavior you want before diving into the bowels of xsane and attempting to fix it. Let me rephrase my question: If xsane simply took the directory part of the last file saved and used it for subsequent file saving operations, would that be acceptable?
(In reply to comment #6) > You seem to imply that I'm arguing that it's somehow your fault that this > doesn't work, Not at all. I am just trying to explain an observed behaviour of xsane-0.997-10.fc13 _and_ its file chooser and it appears that I have to do over and over. I have only one machine (x86_64) with a scanner and xsane does not even start without finding such device so it is hard to experiment with different setups. I only know that before F11->F13 upgrade scan locations/names were not an issue although is quite possible that "working_directory" is a leftover from the past. > If xsane simply took the directory part of the last file > saved and used it for subsequent file saving operations, would that be > acceptable? That is roughly what I wrote in comment 3. So an answer is again "yes"; with that proviso that if absolute file names are indeed required then file chooser operations should provide these and reliably too on the top of that.
(In reply to comment #6) > You seem to imply that I'm arguing that it's somehow your fault that this > doesn't work, but I'm rather just trying to find out what exact behavior you > want before diving into the bowels of xsane and attempting to fix it. Let me > rephrase my question: If xsane simply took the directory part of the last file > saved and used it for subsequent file saving operations, would that be > acceptable? 2010-09-13 This is on a new computer with fedora 12. I think everything was working ok on the old computer running fedora 10. I would like it to be like it was some months ago. At that time if I used the "Browse for image name" icon I could pick a new directory and change the image name. The next time I would run xsane the last working directory and name would be the directory and name appearing in "File name for scanned image". Now when I do this to change the name and working directory the name and directory remains the same as it is when I open "Browse for image name." Now the only way to change the Directory or File Name is to use the "File name for scanned image" line to the right of the icon. ----------------------------------- Ok. Now I've tried agin and may be able to explain better. I previewed a new item. I went to the "Browse for image name" icon and changed only the name in the text box at the top. - The existing name was "xyz0002.jpg." I changed "xyz0002" to "new" and it now read "xyz.jpg" I accepted this. OK and just hitting the ENTER produce the same result. The "File name for scanned image" remained at "....xyz0002.jpg" I hit SAVE and I got a new .jpg image "xyz0002.jpg" with the "File name for scanned image" was now incremented to "xyz0003.jpg" I then modified the "File name for scanned image" to "....newname.jpg" and hit SAVE and the image was saved with that name. I closed and reopened xsane and "File name for scanned image" remains at "....newname.jpg" I looks to me that the "Browse for image name" window is not working. ------------------ >If xsane simply took the directory part of the last file > saved and used it for subsequent file saving operations, would that be > acceptable? Yes. That would be acceptable. It seems to me that I used to be able to change the directory too but this would be "acceptable."
Oops I just reread >If xsane simply took the directory part of the last file > saved and used it for subsequent file saving operations, would that be > acceptable? I must say that "no." The icon is for "Browse for image name." If you cannot change the image name it wouldn't make sense - to me. My uniformed guess is that the "Browse for image name" window is not passing the parameters to the rest of the program. But you probably already know that and the problem is - why isn't it?
The bottom line is that it is impossible to scan to any place other than the home directory. I switched to Fedora 14 from Ubuntu 10.10. In Ubuntu, I could scan to any directory local or network. In Fedora I cannot. This really need\s to be fixed.
Here is a workaround that may also help with a fix. 1) Choose multipage. 2)Browse to you new location (where you want the file to be stored). 3) scan Now the document is saved in the directory of your choice. We want the browse window in the standard options window to do the same thing for when the save option is selected. We want the program to be able to scan to a directory of our choosing at the time of each scan - just like the multipage window allows you to do. It used to work that way in Ubuntu 10.04. Hope that helps.
Thanks for the info. FYI: I won't get to this for a while on account of being abroad on holiday, see https://fedoraproject.org/wiki/Vacation
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is alive and well in Fedora 14 too. See also comment 10.
I do observe this problem too. ( fc14.x86_64 , xsane-0.998-3.fc14.x86_64 ) The "Browse for image filename" did not seem to be doing anything so I downloaded and compiled the source for xsane-0.998 in hope of finding a solution. However, even though I did not make any changes to the code, the dialog seems to be working fine with the binaries that I've compiled. Regards.
Created attachment 536590 [details] Proposed fix This patch fixes the long standing bug of redhat/fedora build of xsane that prevents changing the "save file name" by using the gtk file chooser dialog. The problem is caused by improper check of the return value from xsane_back_gtk_get_filename. Apply the patch to a patch xsane-0.997-no-file-selected.patch that exists in source RPM. Upstream does not contain this bug.
I debugged it and found a problem in 5 minutes. There's a very simple reason for this to happen. I wonder how it took more then a year for anybody to find this simple bug. The upstream version of xsane doesn't have this problem. It was introduced whenever the xsane-0.997-no-file-selected.patch got introduced. In essence, it tried to fix the problem of user not selecting any file and hitting ok, or other errors in gtk file chooser dialog. The only problem is, the fix was incorrect. The patch checks the value returned by xsane_back_gtk_get_filename. In most places it will check the result properly (taking 0 for success), except one case where it takes 0 for an error, and this happens in xsane_browse_filename_callback (xsane-front-gtk.c). The new code would abort copying the filename into preferences structure if 0 was returned, and that's the OK case. I'm very curious how wonderfully it would blow up if an actual error was returned, but that's a different story. Anyway, attaching one-liner patch-to-a-patch. The fix is to change the on-zero test of a return value into a negative test: -+ if (!xsane_back_gtk_get_filename(...)) ++ if (xsane_back_gtk_get_filename(...) < 0)
Almost 4 months later, and I can confirm this is also in Fedora 16. Thanks for the fix anyhow, got tired of waiting, and re-compiled the rpms.
This bug is still present for me in Fedora 17.
Come on, Nils The fix is there. This will not go away by upstream changes soon, not because xsane does not change a lot, but because the bug is in a Fedora added patch. First reports are for F13, and in F17 it is still alive! Zap it, please. Thanks.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #21) > Often a > more recent Fedora release includes newer upstream software that fixes > bugs or makes them obsolete. See comment 19 and comment 20. This is actually a bug introduced by Fedora.
the update to xsane-0.998-12 once again included this erroneous patch: xsane-0.997-no-file-selected.patch Please look at Comment #17 to see how this patch should be fixed, and actually fix it
This bug prevents me from any use of xsane but copying to printer. I confirm that it is not possible to use file chooser dialog to select the target directory for scanned images. It's a pity that such a powerful tool is broken by a wrong patch.
Fedora 18 has arrived, and the bug is still very much alive.
Created attachment 715641 [details] patch for wrong fix in xsane-0.997-no-file-selected.patch This is a patch to be applied after xsane-0.997-no-file-selected.patch Basically Pavel's solution, but now directly as a later patch, not a patch for the patch.
Yes it works. I've added Rene's patch, rebuilt the package and now it works fine, and I can select directories and files in it.
Sorry for dropping the ball on this, really, I can't say why this bug and the fix escaped my notice so far. Pavel, thanks for poking me about this. xsane-0.999-3 is building for F-17..19 and Rawhide.
xsane-0.999-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xsane-0.999-3.fc18
xsane-0.999-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xsane-0.999-3.fc19
xsane-0.999-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xsane-0.999-3.fc17
Package xsane-0.999-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xsane-0.999-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-12382/xsane-0.999-3.fc19 then log in and leave karma (feedback).
xsane-0.999-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
xsane-0.999-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.