From: SourceForge.net <no...@so...> - 2012-05-30 07:17:43
|
Bugs item #3062069, was opened at 2010-09-08 10:10 Message generated for change (Comment added) made by jarekczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3062069&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: editor core Group: severe bug >Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Airman Dan (airmandan) Assigned to: Matthieu Casanova (kpouer) Summary: Save Failure in Program Files (x86) Initial Comment: It is impossible to edit files stored within a directory named "Program Files (x86)" on Windows 7. The editor wrongly assumes that %PROGRAMFILES% will point to the save location, when that variable actually resolves to "Program Files". Consequently, files opened from a directory inside "Program Files (x86)" will be assumed to be located within %PROGRAMFILES% when they are, in fact, not. I have not yet figured out where the saved files *actually* go, but they don't go to where they're supposed to. Running jEdit 4.3.2 server mode, Java 1.5.0_06 ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-05-30 00:17 Message: The entry has been pending for 14 days or more and is being closed now. The procedure is described in wiki: https://sourceforge.net/apps/mediawiki/jedit/index.php?title=Bug_tracker_details#Pending ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-04-22 23:16 Message: Just tested on jedit 4.5.2 with java 6. Works properly both on java 32 and java 64. In the latter case the path displayed id %PROGRAMFILES(X86)%\path\to\file\ Airman, is it ok after upgrade? ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-04-22 05:05 Message: What java are you running, 32, 64? Give us first lines from activity log or issue "java -version". Additional questions: 1. What is the filename you try to edit? 2. You edit the file, save it, but the original file is not modified, right? 3. What do you get in cmd.exe running "echo %PROGRAMFILES%"? ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2011-12-06 11:53 Message: This mismatch of environment variables is caused by jEdit having a different environment from your Windows Explorer. This environment must have been changed so that jEdit thinks %PROGRAMFILES% points to something else. Did you start the process in a windows shortcut that is emulating 32-bit mode or something? Is this something we can even fix in jEdit? ---------------------------------------------------------------------- Comment By: Airman Dan (airmandan) Date: 2010-09-08 11:13 Message: 1) That is correct. 2) I opened them from Explorer, right-clicking the file and selecting "Edit with jEdit." 3) That is correct. 4) The files do not appear in Explorer, nor do they appear in a directory listing from the command prompt. They *do* appear in jEdit's Open dialog, but nowhere else. Reviewing the activity log, the files are saved to %PROGRAMFILES%\path\to\file which doesn't actually exist; should be \Program Files (x86)\path\to\file. ---------------------------------------------------------------------- Comment By: Robert Schwenn (rschwenn) Date: 2010-09-08 11:09 Message: First some questions: 1) The Variable %PROGRAMFILES% point to "x:\Program Files", doesn't it? 2) How did You open the files from "x:\Program Files (x86)" - from within jEdit or via batch, right-click menu ...? 3) After You opened such a file, jEdit shows the path %PROGRAMFILES% instead of "x:\Program Files (x86)"? 4) Did You look for the saved files with the help of 64-bit programs? Background: When a 32-bit program looks for "x:\Program Files", 64-bit Windows 7 *silently* redirects this access to "x:\Program Files (x86)". So, the 32-bit program "thinks" it works under "x:\Program Files" but does not! (same with "x:\Windows") I guess, this feature leads to some quirks, especially when more than one program is involved in a working process. If You confirmed question (3) it might be an approach to dig into the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3062069&group_id=588 |