GNOME Bugzilla – Bug 786302
GIMP not handling Windows directory structure correctly
Last modified: 2017-08-17 17:20:53 UTC
I don't know why this has not been reported before since it's a major Windows issue with GIMP. Maybe it has and I missed it during my search of bugs. GIMP is not handling the Windows 7 directory structure correctly. In win 7, Microsoft introduced virtual folders and symbolic links called junction points. I am wondering if somehow GIMP is getting mixed up with those new additions. Under C:\Users\username\AppData, where C:\ is the Windows root directory, there are three sub-directories: Local, LocalLow, and Roaming. If during a Save operation I double-click on Roaming in Windows Explorer, there should be 54 sub-directories (folders)and the GIMP Save dialog is only showing one sub-directory. At the top left of the GIMP save dialog, there is a dialog, "Save in folder". Beside that dialog are 4 boxes titled, \, Users, Username, and Roaming, as in C:\Users, Username, Roaming. That is wrong, it should be listed as \,Users, Username, AppData, Roaming. AppData is a major sub-directory under the 'Username' sub-directory and it is missing. When I click on Roaming I see only one folder where there should be 54 folders. Under the Username sub-directory I can see the GIMP 2.8 sub-directory but I cannot see the Local or LocalLow sub-directories. The AppData subdirectory is not listed and that represents a major breakdown in the directory listings under the GIMP save dialog.
Please note, the same applies to Export As. Also, there is a Roaming directory under C:\Users\Username as well. That's not the directory I mean. There should be two directories under C:\Users\Username called AppData and Application Data and neither show up in the GIMP Save or Export dialog windows. I know for sure Application Data is one of the new virtual directories added in Win 7, if you click on it you get an error message with Access Denied. That is not true with the AppData directory but I'm wondering if it is somehow related to the virtual directores or junction points and is not showing up in GIMP.
Created attachment 357609 [details] Gimp Win 7 appuser directory listing This file is a sample of the GIMP Win 7 c:\users\appuser\ directory. It's plain that the directories AppData and Application Data are not displayed, as well as several other directories. This is the directory listing that appears during the Save, Open, and Export As dialogs.
Created attachment 357610 [details] partial Win 7 File Explorer view of appuser directory. This is the actual directory view in Windows Explorer of the c:\Users\appuser directory. Note that the directories AppData and Apllication Data are listed. I need to access the AppData\Roaming directory and it is inaccessible in GIMP.
Please note: I am trying to access the c:\Users\<appuser>\AppData\Roaming directory in GIMP and the Appdata directory is not listed in the GIMP directory listings. There may be some confusion since there is also a Roaming directory under c:\Users\<appuser>. I am not referring to that directory but my initial description of the bug may have lead the reader to presume that. The Roaming directory to which I refer is a major directory in Win 7 and is found as c:\Users\<Appusers>\AppData\Roaming. It may not be clear what I mean by appuser, which I should have listed as <appuser> to indicate it is a directory with a variable name. The actual name of <appuser> will be the name assigned by the user. I did not want to list my appuser name for reasons of confidentiality.
I have made a poor assumption in part 1 of this bug. I presumed the directory c:\Users\<appuser>\Roaming is the same directory as c:\Users\<appuser>\AppData\Roaming. I presumed the Roaming directory that shows up in C:\Users\<Appuser>\Roaming was the same directory as c:\Users\<Appuser>\AppData\Roaming, with the directory AppData failing to show up in GIMP. That was wrong. The entire sub-directory chain of Appdata\Roaming fails to show up in GIMP. Sorry if I have mislead anyone. To clarify <appuser>, Windows asks for a user name when it is set up so it can identify different users. If I supply the name foobar as my user name, the above directory chain will be c:\Users\foobar\AppData\Roaming. The directory AppData is a very important directory in Windows 7 but GIMP is not showing it. GIMP does not show c:\Users\<appuser>\Application Data either. This is a virtual directory but if the link to it is broken, Win 7's directory structure become erratic, acting like an infinite loop.
I can not confirm this for Windows 10. The AppData folder (and all its subfolders) shows up in all open- and save-file dialogs. Could you try to navigate to the C:\Users\<Appuser>\AppData\Roaming directory directly by typing in its path in the open file dialog (you can type in a path if you click the pencil icon in the upper left window corner, left from the breadcrumb line)? And as you already said: C:\Users\<Appuser>\Roaming is not a directory that comes with Windows. Most likely it was created by an application that tried to write to C:\Users\<Appuser>\AppData\Roaming and somehow got the path wrong (in fact I have the same folder on one of my PCs and it was created by some third party driver).
If I type C:\Users\<Appuser>\AppData\Roaming into the Open file dialog box in the 'Location' box it will show the proper directory structure. However, when I first open the Open file dialog, it opens to the <appuser> directory and there is no indication of a directory called AppData. If I type c:\users\<appuser>\appdata into the Open file 'Location' dialog box GIMP will open the proper directory structure. Above the Location dialog box you can see 4 buttons labeled \, users, <appuser>, appdata. With the appdata button pressed, I can now see the proper directory structure with sub-directories Local, Local High, and Roaming. If I now press the <appuser> button to the left of the appdata button, I get the full and proper directory structure with AppData, Application Data, etc. Why the proper directory structure does not show when GIMP's Open file dialog box is first opened is a mystery. While I had Gimp open I loaded a file via the Open file dialog. I navigated to a folder I have created under C:\users\ called gimp temp. That shows up on the top left of the dialog box under 'Save in folder" with 4 buttons labeled \, users, <appuser>, gimp temp. If I step back one button and press <appuser> the full directory structure in now there. It seems GIMP has learned about the directory structure from forcing the path in the Open file dialog. Amazing if that's true. I shut GIMP down and re-opened to verify but I'll have to recheck after a reboot. You can confirm what I have told you previously by looking at the screenshots I attached. There was definitely no AppData directory available under c:\users\<appuser>. It has been that way for over a month now, since I first installed GIMP.
sorry...missed this part. You said: "And as you already said: C:\Users\<Appuser>\Roaming is not a directory that comes with Windows". As long as I've had Windows 7, which is at least 5 years, that directory structure has been there. Microsoft maintains a sub-directory under c:\users\<appuser>\AppData\Roaming which is full of data directories. In fact, most apps store data in the AppData directory.
I can't reproduce this at all - for me, the c:\users\<appuser>\AppData\ directory and its subdirectories and all of their subdirectories show up in all of GIMP's file dialogs, with 2.8.22 on Windows 7 64 Bit.
(In reply to Michael Schumacher from comment #9) > I can't reproduce this at all - for me, the c:\users\<appuser>\AppData\ > directory and its subdirectories and all of their subdirectories show up in > all of GIMP's file dialogs, with 2.8.22 on Windows 7 64 Bit. It's the strangest thing, since I forced the path c:\users\<appuser>\AppData\ in the Open dialog 'Location' bar, it has been working fine. You can see by my attached screen shots that the AppData sub-directory is definitely not there. If this keeps up I'll be happy because GIMP is a very good app. That was the only complaint I had, that I could not access the AppData directory. Hopefully it holds and thanks for the comments. I should have mentioned that I am using Win 7 64 bit with SP1 and all the latest updates.
The file dialog do not show hidden files and folders by default. Now, AppData and any of its immediate subfolders aren't marked as hidden on my system, but maybe they are on yours.
(In reply to grobertson49 from comment #8) > sorry...missed this part. You said: > "And as you already said: C:\Users\<Appuser>\Roaming is not a directory that > comes with Windows". > > As long as I've had Windows 7, which is at least 5 years, that directory > structure has been there. Microsoft maintains a sub-directory under > c:\users\<appuser>\AppData\Roaming which is full of data directories. In > fact, most apps store data in the AppData directory. I think you misread the directory path, I mentioned: C:\Users\<Appuser>\Roaming is NOT a Windows directory while C:\Users\<Appuser>\AppData\Roaming definitely IS. (In reply to Michael Schumacher from comment #11) > The file dialog do not show hidden files and folders by default. > > Now, AppData and any of its immediate subfolders aren't marked as hidden on > my system, but maybe they are on yours. AppData is actually hidden on my system and is still visible in the file dialog. Gimp's file dialogs even show the "System Volume Information" and "$RECYCLE.BIN" folders on each hard drive which are system directories and therefore not visible in Windows Explorer, even if the option to show hidden directories is set to true.
"System Volume Information" and "$RECYCLE.BIN" are hidden and shown depending on the corresponding GTK+ file dialog setting - in short, everything seems to work as expected (GTK+ dialogs likely don't care about the "System file/folder" which is used to hide additional files and folders from Windows Explorer). So, with the installer for GIMP 2.8.22 from gimp.org and Windows 7 64 bit, I can reproduce neither issue mentioned in this bug so far.
Ok, I think now i know what happened on grobertson's machine: I just deleted all gtkfilechooser.ini files I could find from my system and restarted gimp. When opening a file dialog, gtk created a new gtkfilechooser.ini in %LOCALAPPDATA%/gtk-2.0 with the setting "ShowHidden" set to false - so the default for all file dialogs is to not show hidden files. Since AppData is hidden, it will not be shown. If you visit AppData once by using the text box in the file dialog, the ShowHidden settings changes to true - but ONLY if you use the breadcrumb buttons to go back into your user folder after that. I guess this happens in order to be able to select the AppData folder to show where you came from. The setting does not get changed back to its previous value after that and this is the reason why you can always see the AppData folder from there on. Maybe I somehow did exactly this procedure while I was working on something inside AppData and therefore already had the ShowHidden setting set to true. Although this is not really a bug, it is kind of an counter-intuitive behavior by gtk, imho. Just visiting a directory should not change which folders I can see in a file dialog. I'd only expect the setting to change when toggling a checkbox or editing the settings file by hand.
If we want to pursue this further, we should file a bug against GTK+ - after we checked if there already has been one, which might have resulted in the current behavior. I'm tempted to close this current report as NOTABUG - after all, the file dialogs did just what they are supposed to do: not showing hidden files and folders. The actual folders involved are not relevant.
(In reply to Michael Schumacher from comment #11) > The file dialog do not show hidden files and folders by default. > > Now, AppData and any of its immediate subfolders aren't marked as hidden on > my system, but maybe they are on yours. I have all files and system files unhidden. Have never noticed if AppData is intended to be hidden but it's not hidden on my setup. It has always appeared in Windows Explorer.
(In reply to Simon Müller from comment #14) > Ok, I think now i know what happened on grobertson's machine: > > I just deleted all gtkfilechooser.ini files I could find from my system and > restarted gimp. When opening a file dialog, gtk created a new > gtkfilechooser.ini in %LOCALAPPDATA%/gtk-2.0 with the setting "ShowHidden" > set to false - so the default for all file dialogs is to not show hidden > files. Since AppData is hidden, it will not be shown. > That's interesting. Since I have all files (Windows MFT treats everything as a file...including folders and links) marked as unhidden, where would GIMP retrieve the information as to whether AppData was hidden or unhidden? Obviously, if AppData is supposedly marked as unhidden in Folder Options, as it is on my system, GIMP must be retrieving its hidden status from somewhere else? If I right-click the AppData folder and look at 'Properties' it is marked as 'Hidden' even though it appears in Windows Explorer. In Folder Options under Control Panel(I'm using Classic View), under the view tab, there is an option called "Hidden Files and Folders). I have it marked to 'Show hidden files, folders and drives'. Further down there is an option to 'Hide protected operating system files' and I have that unchecked. Yet, under Properties when I right-click the AppData folder, it shows it as 'Hidden'. There are attributes in the MFT (Master File Table) to alter that but getting at them is not that easy. I wonder if this is a Windows bug in the MFT? I just unclicked the 'Hidden' attribute under Properties and it asked if I want to apply unhide to all files/folders in AppData. It is taking 17 minutes to do them all. > > Although this is not really a bug, it is kind of an counter-intuitive > behavior by gtk, imho. Just visiting a directory should not change which > folders I can see in a file dialog. I'd only expect the setting to change > when toggling a checkbox or editing the settings file by hand. I am wondering if there is a key in the Registry being monitored by gtk.
(In reply to Simon Müller from comment #12) > I think you misread the directory path, I mentioned: > C:\Users\<Appuser>\Roaming is NOT a Windows directory while > C:\Users\<Appuser>\AppData\Roaming definitely IS. > > On my system there is a folder called Roaming under C:\Users\<Appuser>\Roaming. There is only one folder in it marked 'Intel'. I am thinking Intel may have entered the wrong path in their installer. That's the directory I mistook initially for the real Roaming directory and became confused as to what had happened to the AppData directory.
(In reply to Michael Schumacher from comment #15) > If we want to pursue this further, we should file a bug against GTK+ - after > we checked if there already has been one, which might have resulted in the > current behavior. > > I'm tempted to close this current report as NOTABUG - after all, the file > dialogs did just what they are supposed to do: not showing hidden files and > folders. The actual folders involved are not relevant. Michael, I'd have to agree. There may be an issue with Windows itself in the way it displays hidden files. I explained this in an earlier post. I have removed the Hidden attribute under AppData/Properties and hopefully that does not create issues for me elsewhere. Meantime GIMP seems to be working fine. Thanks for support.
(In reply to grobertson49 from comment #17) > where would GIMP retrieve the information as to whether AppData > was hidden or unhidden? Obviously, if AppData is supposedly > marked as unhidden in Folder Options, as it is on my system, > GIMP must be retrieving its hidden status from somewhere > else? The "hidden" attribute that you can see in the properties dialog is actually an attribute of the file itself. Those attributes are part of the file system (FAT, NTFS, ...) and have nothing to do with Gimp or Windows (and therefore have nothing to do with the registry). On a standard Windows installation, the hidden attribute is set for the AppData folder and every application (including Windows Explorer) can decide what to do with that information. This is the reason why there is a setting to show or hide hidden files. But let's discuss this on IRC, the bugtracker is not the right place for this kind of digressions.
(In reply to Simon Müller from comment #20) > The "hidden" attribute that you can see in the properties dialog is actually > an attribute of the file itself. Those attributes are part of the file > system (FAT, NTFS, ...) and have nothing to do with Gimp or Windows (and > therefore have nothing to do with the registry). You're right, this should not be discussed here, but allow me to say in closing that I have delved into the NTFS/MFT system at depth and I was able to toggle the hidden attributes of any file or folder, including MFT hidden files. In the NTFS system, which uses the Master File Table in lieu of FAT, everything is treated as a file, even folders. Changing the attributes on a folder is now exactly the same as the old DOS method of using attrib. It's much more involved in the MFT but essentially the same. You flip the proper bit and the status is changed. The old DOS system had read only, hidden, and system file attributes that could be toggled by the attrib command. Obviously toggling the Hidden attribute in the AppData properties box is not writing directly to the MFT, user level commands and user-level windows cannot access it directly. There is a chained interface via Shell32.dll with which user apps contact the MFT. Since the registry is a Windows database, I was reasoning it might store data associated with the status of a hidden file for use by Shell32.dll. Long before you reach the MFT, there are data structures created to tell the MFT access functions in the Windows system what needs to be looked up. There is a registry key in which you can turn on/off the general hide/unhide features in Windows file system, as found in Control Panel/Folder Options/View: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced but I'm sure individual file/folder attributes can only be accessed via the MFT. When you click or unclick the Hidden box in AppData/Properties, the box is processed through Shell32.dll where it is determined what action is required in the MFT. I'm sure Windows keeps a separate list of which folders can be hidden/superhidden so the MFT processing functions can do bulk changes. All files/folder in an NTFS system are referenced through the MFT. I don't know how GIMP processes files in Windows. If it looks up the registry key above, it could determine whether system and other hidden files are hidden/unhidden and proceed on that basis. It seems strange, however, that the registry value is marked Hidden = 1, which mean NOT hidden, and the properties box showed Hidden for the folder AppData. Clearly, Windows operates in mysterious way, something I've had to accept since the mid-'80s.
(In reply to Simon Müller from comment #14) > I just deleted all gtkfilechooser.ini files I could find from my system and > restarted gimp. When opening a file dialog, gtk created a new > gtkfilechooser.ini in %LOCALAPPDATA%/gtk-2.0 with the setting "ShowHidden" > set to false - so the default for all file dialogs is to not show hidden > files. Since AppData is hidden, it will not be shown. > Just for the record. I could not find that ini file in %LOCALAPPDATA%/gtk-2.0. I found it in %LOCALAPPDATA%\Local\gtk-2.0. It's now set to ShowHidden=true. The 'Local' sub-folder under AppData contains the Temp directory as well where Windows apps do temporary work. The Local and Localow directories under AppData are for local temporary storage. If the gtkfilechooser.ini file is deleted after each session of GIMP it seems appropriate to keep it in Local. However, the main GIMP app data folder is stored under the <appuser> sub-directory, not the AppData directory. At least, on my system that's the case.
GIMP uses GTK+ as it UI toolkit, and one thing GTK+ provides is the file chooser dialog (and widget). At some point, GTK+ does access the Windows API, of course. GTK+ also takes care of where any possible ini files or other settings are located. GIMP can happily remain oblivious to all that.