You are not logged in.
- Topics: Active | Unanswered | Last 2 weeks
#1 2017-10-18 00:54
- aip1000
- Member
- Registered: 2016-08-15
- Posts: 8
[Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Application Version:
6.7.0.7 Beta
Steps to Reproduce:
Create Presets inside a Subfolder:
Images\Images
Images\Images.Case
Images\Images.Test
Execute Presets → Rescan
Verify the Image Submenu is created
Apply SYSTEM attribute to the Images Subfolder (
attrib +S Images
)Execute Presets → Rescan
Verify the Image Submenu is created
Expected Result:
There should be a Submenu "Images" under Presets
Actual Result:
The "Images" Submenu appears initially, but disappears after adding the SYSTEM attribute to the directory
Additional Information:
Windows will automatically set the +S attribute in some cases, such as a folder with a custom icon, so it would be helpful to include SYSTEM directories when scanning for presets.
PS: Thanks for fixing the other bug so quickly!
Offline
#2 2017-10-19 20:29
- den4b
- Administrator
- From: den4b.com
- Registered: 2006-04-06
- Posts: 3,370
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Thank you for a detailed report!
System and hidden folders are skipped intentionally (by design).
However, what you have said about the customized folders, that Windows marks such folders with SYSTEM attribute, seems very strange. We were unable to reproduce this behavior with Windows 7 and 10.
Can you please verify and demonstrate that this indeed happens on your system?
Unless this is a common behavior (or misbehavior) in Windows, it would seem inappropriate to include SYSTEM folders when scanning for presets.
Offline
#3 2017-10-19 22:08
- aip1000
- Member
- Registered: 2016-08-15
- Posts: 8
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Hi,
Yes, this is documented Windows behavior.
Here's an MSDN article on the topic:
Note the following excerpt:
Use the following procedure to customize a folder's style with Desktop.ini:
Use PathMakeSystemFolder to make the folder a system folder. This sets the read-only bit on the folder to indicate that the special behavior reserved for Desktop.ini should be enabled. You can also make a folder a system folder from the command line by using attrib +s FolderName.
Offline
#4 2017-10-19 22:21
- aip1000
- Member
- Registered: 2016-08-15
- Posts: 8
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
And here are some screenshots demonstrating this behavior:
Icon Folder +SYSTEM
Icon Folder -SYSTEM
Offline
#5 2017-10-20 17:19
- den4b
- Administrator
- From: den4b.com
- Registered: 2006-04-06
- Posts: 3,370
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Thank you for finding that reference article on MSDN.
That is a bizarre use of the SYSTEM attribute. Nonetheless, I guess we'll just have to follow their lead on this and include SYSTEM directories when scanning for presets.
This change will be incorporated in the next development version.
Offline
#6 2017-10-20 22:21
- Andrew
- Senior Member
- Registered: 2008-05-22
- Posts: 542
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Use PathMakeSystemFolder to make the folder a system folder. This sets the read-only bit on the folder to indicate that the special behavior reserved for Desktop.ini should be enabled. You can also make a folder a system folder from the command line by using attrib +s FolderName.
So PathMakeSystemFolder makes a folder a system folder by setting its read-only bit, and to do the same yourself you should use attrib +s? WTH? Who writes these MSDN articles anyway, unpaid interns? 
The issue is actually a bit more nuanced than this typically incorrect and incomplete MSDN article suggests, which is why I recommend not including +S/SYSTEM folders when scanning for presets.
As per this old PC Magazine article:
For Windows Explorer to recognize that a folder has a custom icon, the folder must have the System attribute set. Starting with Version 4.71 (the version required by Folders), Shell32.dll includes several functions related to system folders--specifically PathMakeSystemFolder, PathUnmakeSystemFolder, and IsSystemFolder. You would expect these functions to set a folder's System attribute, clear the System attribute, and report whether the attribute is set. Thus, you'll probably be as surprised as I was to learn that they actually set, clear, and report on the Read-only attribute instead.
He's only partly correct; actually "For Windows Explorer to recognize that a folder has a custom icon, the folder must have the System or Read-only attribute set." Moreover, Windows by default only sets a folder's Read-only attribute when its icon is customized via the folder's Properties dialog > Customize tab. That is why the 3 API functions above set, clear, and report on the Read-only attribute instead of the System attribute by default.
There is a mostly undocumented trick however to make Windows set a folder's System attribute when its icon is customized. This is mentioned on this page about the PathMakeSystemFolder function:
A system folder must have either the read-only or system attribute set. This function sets one and clears the other. The choice depends on the UseSystemForSystemFolders value under the Software\Microsoft\Windows\CurrentVersion\Explorer key in the HKEY_LOCAL_MACHINE branch of the registry. The attribute that the function sets is the system attribute, if this value is present, else the read-only attribute.
To be even more clear, here's a quote from the book Mastering Windows XP Home Edition:
If you actually need to change a customized folder, you can use this trick to make XP use the system attribute rather than the read-only attribute to mark custom folders. In the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer subkey, create a new DWORD value entry named UseSystemForSystemFolders, assign it the value 1, and reboot your computer. [Edit: I tested this and confirmed it still works in Windows 10 1709, although no reboot was required.]
Note that there is no mention of UseSystemForSystemFolders in any MSDN KB article now. It was detailed in KB256614 (as you can see via the Web Archive), but that redirects to KB326549 now which omits any mention of the same. The closest one gets to an official statement is this old MSDN blog post by a well-known Mcrosoft employee:
There are two ways to mark a folder as having nondefault UI. One is to set the FILE_ATTRIBUTE_READONLY attribute, and the other is to set the FILE_ATTRIBUTE_SYSTEM attribute.
Either one works, and PathIsSystemFolder checks for both, returning a nonzero value if either attribute is set.
In its default configuration, Windows uses the read-only flag to mark folders with nondefault UI. However, some applications mistakenly believe that if a directory is marked read-only, then files within the directory cannot be modified. As a result, these applications refuse to let you save your documents onto the desktop, for example. To work around this, you can use the UseSystemForSystemFolders to tell Windows to use the FILE_ATTRIBUTE_SYSTEM attribute instead. Of course, if you do that, you will run into problems with applications which mistakenly believe that if a directory is marked system, then the directory is inaccessible. So you get to pick your poison.
tl;dr:
Windows by default sets the +R attribute of a customized folder.
For Windows to recognize that a folder has been customized (with a desktop.ini file), either the +R or +S attribute will work.
To make Windows set the +S attribute of a customized folder by default instead, one needs to explicitly edit the registry and employ the undocumented (and possibly deprecated) UseSystemForSystemFolders DWORD (that I can guarantee vanishingly few ReNamer users will even have a clue exists).
Based on the above, since Windows' default behavior is to use +R for customized folders and ReNamer seems to have no problems with Preset subfolders marked Read-only, I see no good reason why the program should not continue to ignore folders marked as System so as to prevent any potential mishap.
Last edited by Andrew (2017-10-20 22:22)
Offline
#7 2017-10-21 12:48
- den4b
- Administrator
- From: den4b.com
- Registered: 2006-04-06
- Posts: 3,370
Re: [Bug Report] Presets Menu: Directories with +S Attribute are Ignored
Andrew, thank you for digging out these additional references.
So, either READONLY or SYSTEM attribute may be used on customized folders to enable special behavior reserved for Desktop.ini. A setting in the registry is used to determine which exact attribute will be used. Microsoft developers have made a mess of it.
My initial instinct was to avoid processing SYSTEM folders, but after finding out that this is a documented behavior - I see no choice but to include SYSTEM folders when scanning for presets.
Note that this search operation occurs only within the Presets folder. It should be safe to assume that it contains only the presets related material, as opposed to actual system folders required by the operating system. The search operation finds all *.rnp files and folders which have none will not show up in the presets menu.
aip1000, are you aware of the above registry entry for toggling which attribute to use for marking customized folders? Did you ever change that registry entry, or this is just how your system operates normally?
Offline