I'm using the locate function (in FileFunc.nsh) to search windows drive (which is C:\ in this case) for a file. Whenever it gets to "C:\Recycled" it crashes the installer, with a Windows XP "0x00000005: Access Violation". I looked into it and apparently "C:\Recycled" is NOT A REAL DIRECTORY! It is actually a subdirectory (with a different name) under "C:\Recycler", which is hidden. I would prefer that Locate skip this folder entirely, but I don't see any way to do that without getting an advanced plugin (I cannot do that-don't ask).
This seems to me to be some sort of bug. I dunno why I couldn't find a post about this.
I'm looking for either a solution or ... a bugfix(?).
Locate crashes on C:\Recycled
11 posts
Sorry for the long post, but I have found a few things that might be helpful here:
First, I did my own research (thanks to Google) and found something interesting about the "C:\recycled" folder. The best article I found on the topic was here.
Basically, the folder "C:\Recycled" was the name of the recycle bin on Win9x computers. When upgrading to XP, the folder gets replaced by "C:\recycler" (which is the standard folder I've seen on most other XP boxes). Furthermore, the original "C:\recycled" folder may have it's attributes/permissions set in such a way that prevents access. So, my first suggestion would be to check the file attributes and security settings on your "C:\recycled" folder to see if perhaps you just don't have enought permissions or that perhaps the folder isn't read-only.
Next, I did some of my own testing that seems to support the above theory:
I created my own folder with no permissions and ran a search with the Locate plugin. Something a bit odd happened: I found that the LOCATE macro assigned a size ($R6) to the "permission-less" folder, even though according to the docs, folders are supposed to return a null value ("") for $R6. As soon as I gave permissions back to the folder, the macro once again worked as expected and returned a null value for the folder name. (This is what leads me to believe your issue is likely a permissions problem.)
So, bottom line here is that there appears to be a flaw in the logic in that the plugin is setting a non-null size variable when a folder has no permissions. (Unfortunately, I don't have any clever work-arounds at the moment. You might want to contact the author for help.)
Edit
Just a thought:
If you used the option "/L=FD" (as I did in my example), then you might be able to just check the size in your callback function and if it's zero, just continue on. (This is of course assuming that the file you intend to find not a 0 KB file.)
First, I did my own research (thanks to Google) and found something interesting about the "C:\recycled" folder. The best article I found on the topic was here.
Basically, the folder "C:\Recycled" was the name of the recycle bin on Win9x computers. When upgrading to XP, the folder gets replaced by "C:\recycler" (which is the standard folder I've seen on most other XP boxes). Furthermore, the original "C:\recycled" folder may have it's attributes/permissions set in such a way that prevents access. So, my first suggestion would be to check the file attributes and security settings on your "C:\recycled" folder to see if perhaps you just don't have enought permissions or that perhaps the folder isn't read-only.
Next, I did some of my own testing that seems to support the above theory:
I created my own folder with no permissions and ran a search with the Locate plugin. Something a bit odd happened: I found that the LOCATE macro assigned a size ($R6) to the "permission-less" folder, even though according to the docs, folders are supposed to return a null value ("") for $R6. As soon as I gave permissions back to the folder, the macro once again worked as expected and returned a null value for the folder name. (This is what leads me to believe your issue is likely a permissions problem.)
So, bottom line here is that there appears to be a flaw in the logic in that the plugin is setting a non-null size variable when a folder has no permissions. (Unfortunately, I don't have any clever work-arounds at the moment. You might want to contact the author for help.)
Edit
Just a thought:
If you used the option "/L=FD" (as I did in my example), then you might be able to just check the size in your callback function and if it's zero, just continue on. (This is of course assuming that the file you intend to find not a 0 KB file.)
Comperio
Locate function and Locate plugin are not the same.
Shorin what parameters you use? As suggested Comperio: do you have all permissions to recycled bin folder?
P.S. and better show your code with callback function
Locate function and Locate plugin are not the same.
Something a bit odd happened: I found that the LOCATE macro assigned a size ($R6) to the "permission-less" folder, even though according to the docs, folders are supposed to return a null value ("") for $R6.In the locate function code for check folder or file used command [IfFileExists '...\*.*']. Because files inside doesn't exist "permission-less" folder detected as file. Locate plugin returns "" for "permission-less" folder.
Shorin what parameters you use? As suggested Comperio: do you have all permissions to recycled bin folder?
P.S. and better show your code with callback function
Sorry, I probably used the wrong terms.
I was referring to the ${Locate} macro that is included as part of NSIS, not your stand-alone plugin. (I believe is also what Shorin was also referring to).
I was referring to the ${Locate} macro that is included as part of NSIS, not your stand-alone plugin. (I believe is also what Shorin was also referring to).
Here is my call to the locate plugin:
${Locate} "C:\" "/M=rtsky.ini" "SetSuccess"
The "C:\" is usually supplied with the variable $9, and it has had this value during tests.
Also, regarding permissions to the "Recycled" folder (which definitely seems to be a 'virtual directory' in Windows XP), It shows that it's read only, but the checkbox for that is <B>tri-state</B>. It is in its <I>partially selected</I> state I think. I do not precisely what this means (or even if that state is called the <I>partially selected</I> state). I have not been able to find out what this third state means. Perhaps it means "system".
Also I found something interesting about windows folder attributes just now:
From:
Excerpt
Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer. The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box. As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders. When a folder has the Read-Only attribute set it causes Explorer to <B>request the Desktop.ini of that folder</B> to see if any special folder settings need to be set.
- however I do not see a Desktop.ini in C:\recycled . If anything, the function should be modified so that it does not access that folder, as it is a virtual folder (more like a shortcut).
${Locate} "C:\" "/M=rtsky.ini" "SetSuccess"
The "C:\" is usually supplied with the variable $9, and it has had this value during tests.
Also, regarding permissions to the "Recycled" folder (which definitely seems to be a 'virtual directory' in Windows XP), It shows that it's read only, but the checkbox for that is <B>tri-state</B>. It is in its <I>partially selected</I> state I think. I do not precisely what this means (or even if that state is called the <I>partially selected</I> state). I have not been able to find out what this third state means. Perhaps it means "system".
Also I found something interesting about windows folder attributes just now:
From:
Microsoft Support is here to help you with Microsoft products. Find how-to articles, videos, and training for Microsoft Copilot, Microsoft 365, Windows 11, Surface, and more.
Excerpt
Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer. The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box. As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders. When a folder has the Read-Only attribute set it causes Explorer to <B>request the Desktop.ini of that folder</B> to see if any special folder settings need to be set.
- however I do not see a Desktop.ini in C:\recycled . If anything, the function should be modified so that it does not access that folder, as it is a virtual folder (more like a shortcut).
only way to find desktop.ini is with attrib in a command prompt, its hidden in explorer
I can't reproduce the problem. Maybe you can pack this folder (without trash) and attach it.
more stuff
This is strange. I have NO idea why it failed before. I did get success this past time I ran it. I dunno why this is happening. When it finds the file it actually crashes.
What's all this about (in the documentation) :
(from Locate's topic)
Function "Function"
; $R9 "path\name"
; $R8 "path"
; $R7 "name"
; $R6 "size" ($R6="" if directory, $R6="0" if file with /S=)
; $R0-$R5 are not used (save data in them).
; ...
Push $var ; <B>If $var="StopLocate" </B>Then exit from function
FunctionEnd
I do believe <B>$var</B> should be <B>$0</B> like all the examples.
Ok... so it does work now. But having to push $0 onto the stack with a valie of "StopLocate" to end the function??... That's a somewhat strange way to do things... I think I'm going to investigate this source myself and see if I can put better error catching in this thing.
This is strange. I have NO idea why it failed before. I did get success this past time I ran it. I dunno why this is happening. When it finds the file it actually crashes.
What's all this about (in the documentation) :
(from Locate's topic)
Function "Function"
; $R9 "path\name"
; $R8 "path"
; $R7 "name"
; $R6 "size" ($R6="" if directory, $R6="0" if file with /S=)
; $R0-$R5 are not used (save data in them).
; ...
Push $var ; <B>If $var="StopLocate" </B>Then exit from function
FunctionEnd
I do believe <B>$var</B> should be <B>$0</B> like all the examples.
Ok... so it does work now. But having to push $0 onto the stack with a valie of "StopLocate" to end the function??... That's a somewhat strange way to do things... I think I'm going to investigate this source myself and see if I can put better error catching in this thing.
I think I got these html tags wrong somehow
Also, is it possible to make Locate stop before a search is done? I would like to give impatient users a chance to quit without manually terminating.
Also, is it possible to make Locate stop before a search is done? I would like to give impatient users a chance to quit without manually terminating.See in the docs "Example (Locate with banner - NxS plugin required):"