I have a hard drive and this is a bad file on it! When I want to delete file windows says:
"The file name you specified is not valid or too long.
Specify a different file name."
But the file not renamed! What do I do?
You cannot modify a resource when a running process has a handle to it.
The solution is to end all processes that have a handle to your resource. This is shown below.
1.
End all processes that have a handle to the resource:
Start>>All Programs>>Accessories>>System Tools>>Resource Monitor (or Run resmon.exe)
Search for the resource in the Associated Handles searchbox (circled in red). Look in the Handle Name column to see if any of the processes have a handle to the resource's URI and end those processes by right clicking and selecting End Process.
2.
You should now be able to modify your resource, e.g. delete, rename, move, etc.
Boot an Ubuntu live CD, navigate to the offending folder, and delete whatever files you want. I tried all of the other solutions and none of them worked for me, but Ubuntu did.
Related
I am using Base SAS 9.4 on Windows 7. For various reasons, which are detailed below, some of my programs have extremely long names. Exacerbating this further, the programs are stored deep in the abyss of a network drive. This causes problems when trying to open from Windows Explorer. I believe the problem lies with SAS, but have tagged the question with Windows in case not. I'm hoping there is some way to address this problem via a configuration file or an edit to the registry.
To open a program, I typically double click on the .sas file in Windows Explorer. This opens the Enhanced Editor after a brief waiting period in which a SAS message box states:
The SAS System is processing requests. Please wait...
When a program's full name, including path and extension, exceeds 182 characters (i.e. has form: \\network-location\a\bunch\of\....\folders\program path exceeding 182 char.sas), the same "SAS System is processing requests" message appears, but then a Windows error is generated.
Not surprisingly, no solution is proffered by Windows.
When the program name is such that the full path is exactly 182 characters, nothing happens. I double click on the program and the only result is to select the file in Windows Explorer. If I monitor "Processes" within the Windows Task Manager, no new processes are started when such a program is double clicked.
When the program name is such that the full path is less than 182 characters, the program opens in the Enhanced Editor as expected.
According to MSDN, the max path is 260 characters. Clearly, 182 is well below that limit. SAS is the only application which has a problem with the path length. For example, I can copy the file name and extension, create a new text document with the same name (plus .txt) and open the file in Notepad, Notepad++, Word, Wordpad, Emacs, etc.
I have deduced two workarounds for working with names exceeding 182 characters.
If I open SAS via SAS.exe, I can load a program through the Open dialog with a path exceeding 182 characters just fine. This is not a good solution, however, as the Open dialog does not allow paths to be copy/pasted. The entire file path must be traversed. I can also drag such a program into the editor window within SAS to load it. This too is not a good solution, as a program will only load if there is a blank editor window. If the program is accidentally dragged on the the log window, it will execute automatically. Also, the program does not open in a convenient location. It opens in the middle of the Enhanced Editor and must be manually resized. That the programs can be loaded and executed at all leads me to believe that there is some way to fix this problem. It seems that somewhere in the process of loading the file, SAS violates some variable limit.
Of course, people would suggest that I use a different network location or shorter names. To the former, I am required to use a specific network location. To the latter, these programs are being developed in parallel with various reports. Many of the programs are similar and the corresponding references (table/figure numbers) in the reports change multiple times/aren't always communicated to me. Through experience, I've found the surest way to work with these uncertainties is to simply name the file by the label it's given in the report. Otherwise, I need to adopt unclear abbreviations, bad organizational practices, or introduce intermediate steps (like creating codes or a document which indexes the programs).
Edit: Per Joe's comment, it seems that the Open dialog allows copy and paste for specific file names. A file path can be copied in Windows Explorer via Shift + Right Mouse Click > Copy as Path and pasted into the "File Path" box in the Open dialog.
To avoid traversing the tree, the Current Folder may be updated before accessing the Open dialog. This is located at the bottom right of the Enhanced Editor.
The Open dialog starts at whatever the Current Folder location is set to.
I suspect your issue is that your 260 limit is in fact applicable.
When you double-click a program file, it doesn't just copy the path to SAS. Instead, what happens is SASOACT.exe is called, with a command of something similar to this:
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe" action=Open datatype=Access filename="%1" progid=SAS.Application.940
That's well over 100 characters already by itself; presumably, behind the scenes, you end up with something like
"C:\Program Files\SAS94\SASFoundation\9.4\core\sasexe\sasoact.exe -open ""%1"""
Which adds around 70 or 80 characters to what you're passing it. Thus the 260 character limit.
You should use one of the workarounds - I personally prefer to just file->open, myself, but really whatever works best for you is fine. You could also consider using another editor for the simple double-click actions, though any editor you chose would still have some issues.
You could also consider asking IT to install SAS itself in a location that had a shorter path name, though realistically that might save 10 characters or so.
As for pasting; you can paste a path name just as easily as a file name into the file->open dialog. I have no idea why you don't seem to think you can, but I just did so now with no more difficulty than any other folder dialog...
Another workaround to consider, by the way, is mapping a drive letter to the network path. I.e., if your network path is
//myserver/projects/financial/projectnumber/.../
You map some letter (let's say R: arbitrarily) to that root path, //myserver/projects/financial/projectnumber, which is not changing anything other than how you refer to it locally. Then you can use:
R:\...\filename.sas
And you don't have to navigate paths, etc. You'd have to repeat that mapping process on any machine that you wanted to do this on, but if this mostly about your own workflow, that shouldn't be an issue. Just don't refer to R: inside the program itself and nobody else will ever know that you've changed anything.
I want to improve my file managent and need some help to get started.
For this specific script, my idea is the following:
while in Explorer
rightclick a file -> Send To -> "Apps[.bat]"
Then the script starts and does the following:
moves the whole directory (and subfolders) of the selected file to a specified location (in my case C:\Users\Name\Desktop\Apps\Files)
so sending Name\Downloads\Coolportableapplication\Coolapp.exe to the batch results in Name\Desktop\Apps\Files\Coolportableapplication\Coolapp.exe
creates a shortcut of C:\Users\Name\Desktop\Apps\Files\Coolportableapplication\Coolapp.exe in C:\Users\Name\Desktop\Apps
Is this generally possible with a batchscript?
This isn't my first batch but I've never dealt with unspecified files and English isn't my native language so I couldn't really find anything useful for my cause, though I am sure my little script won't be too much of a problem for you. Based on that batch, I want to create similar scripts but I just have no idea how to begin with that one.
Thanks a lot!
No need for a batch file but anyway.
1: Type shell:sendto into your explorer window and copy the shortcut to your directory "C:\Users\Name\Desktop\Apps\Files". This directory will now show as default in your Send To options.
I am trying to open a .chm file.
I downloaded the source, extracted it, and double clicked on Waffle.chm and clicked "Open" but no matter what element in the chm file I click, I get the message:
Navigation to the webpage was canceled.
What you can try:
Retype the address.
What's going on here?
Summary
Microsoft Security Updates 896358 & 840315 block display of CHM file contents when opened from a network drive (or a UNC path). This is Windows' attempt to stop attack vectors for viruses/malware from infecting your computer and has blocked out the .chm file that draw data over the "InfoTech" protocol, which this chm file uses.
Microsoft's summary of the problem: http://support.microsoft.com/kb/896054
Solutions
If you are using Windows Server 2008, Windows 7, windows has created a quick fix. Right click the chm file, and you will get the "yourfile.chm Properties" dialog box, at the bottom, a button called "Unblock" appears. Click Unblock and press OK, and try to open the chm file again, it works correctly. This option is not available for earlier versions of Windows before WindowsXP (SP3).
Solve the problem by moving your chm file OFF the network drive. You may be unaware you are using a network drive, double check now: Right click your .chm file, click properties and look at the "location" field. If it starts with two backslashes like this: \\epicserver\blah\, then you are using a networked drive. So to fix it, Copy the chm file, and paste it into a local drive, like C:\ or E:. Then try to reopen the chm file, windows does not freak out.
Last resort, if you can't copy/move the file off the networked drive. If you must open it where it sits, and you are using a lesser version of windows like XP, Vista, ME or other, you will have to manually tell Windows not to freak out over this .chm file. HHReg (HTML Help Registration Utility) Utility Automates this Task. Basically you download the HHReg utility, load your .chm file, press OK, and it will create the necessary registry keys to tell Windows not to block it. For more info: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/
Windows 8 or 10? --> Upgrade to Windows XP.
"unblocking" the file fixes the problem. Screenshot:
Win 8 x64:
just move it to another folder or rename your folder (in my case: my folder was "c#").
avoid to use symbol on folder name. name it with letter.
done.
In addition to Eric Leschinski's answer, and because this is stackoverflow, a programmatical solution:
Windows uses hidden file forks to mark content as "downloaded". Truncating these unblocks the file. The name of the stream used for CHM's is "Zone.Identifier". One can access streams by appending :streamname when opening the file. (keep backups the first time, in case your RTL messes that up!)
In Delphi it would look like this:
var f : file;
begin
writeln('unblocking ',s);
assignfile(f,'some.chm:Zone.Identifier');
rewrite(f,1);
truncate(f);
closefile(f);
end;
I'm told that on non forked filesystems (like FAT32) there are hidden files, but I haven't gotten to the bottom of that yet.
P.s. Delphi's DeleteFile() should also recognize forks.
The definitive solution is to allow the InfoTech protocol to work in the intranet zone.
Add the following value to the registry and the problem should be solved:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
More info here: http://support.microsoft.com/kb/896054
Go to Start
Type regsvr32 hhctrl.ocx
You should get a success message like:
" DllRegisterServer in hhctrl.ocx succeeded "
Now try to open your CHM file again.
other way is to use different third party software. This link shows more third party software to view chm files...
I tried with SumatraPDF and it work fine.
I fixed this programmatically in my software, using C++ Builder.
Before I assign the CHM help file, Application->HelpFile = HelpFileName, I check to see if it contains the "Zone.Identifier" stream, and when it does, I simply remove it.
String ZIStream(HelpFileName + ":Zone.Identifier") ;
if (FileExists(ZIStream))
{ DeleteFile(ZIStream) ; }
There are apparently different levels of authentication. Most articles I read tell you to set the MaxAllowedZone to '1' which means that local machine zone and intranet zone are allowed but '4' allows access for 'all' zones.
For more info, read this article:
https://support.microsoft.com/en-us/kb/892675
This is how my registry looks (I wasn't sure it would work with the wild cards but it seems to work for me):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
As an additional note, weirdly the "UrlAllowList" key was required to make this work on another PC but not my test one. It's probably not required at all but when I added it, it fixed the problem. The user may have not closed the original file or something like that. So just a consideration. I suggest try the least and test it, then add if needed. Once you confirm, you can deploy if needed. Good Luck!
Edit: P.S. Another method that worked was mapping the path to the network locally by using mklink /d (symbolic linking in Windows 7 or newer) but mapping a network drive letter (Z: for testing) did not work. Just food for thought and I did not have to 'Unblock' any files. Also the accepted 'Solution' did not resolve the issue for me.
Moving to local folder is the quickest solution, nothing else worked for me esp because I was not admin on my system (can't edit registery etc), which is a typical case in a work environment.
Create a folder in C:\help drive, lets call it help and copy the files there and open.
Do not copy to mydocuments or anywhere else, those locations are usually on network drive in office setup and will not work.
When deleting a folder that contains a file that is in use, it is common to see the following Windows 7 message,
"The action can't be completed because the folder or a file in it is open in another program."
I commonly have 10-20 programs open, 30-40 folders open, etc. In short, I have many executables running and many windows explorers open.
Does anyone know a simple trick to determine which program is using the file?
Does anyone know a simple trick to determine which file is blocking the delete operation?
This information would be highly useful to display in the Windows 7 'folder in use' dialog, but it is missing.
Consequently I have to close many of my open applications and folders to complete the delete operation. This is annoying because I have to re-open them after deleting them.
Have you seen this other question or this one?
I use to run ProccessExplorer and Find for the blocked folder.
Closing the application Malwarebytes allowed me to delete what I needed to via Windows Explorer.
I'm implementing a custom URL handler in .NET. To test this, I have created a few different .url files and put them on my Desktop. This generally works fine, but behaves oddly if I change the file's contents, specifically the URL= line. Doing so has no effect — the old URL continues to be opened. Renaming the file, however, works. The file looks like this:
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,0
[InternetShortcut]
URL=myCustomScheme://some/url/pointing/somewhere
IDList=
All shortcuts I create through New → Shortcut receive the same UUID, so changing that probably won't help.
Is there some internal .url file / URL mapping cache in Windows?
I have a reason to believe that URL files are interpreted by some Internet Explorer component at the time of creation (not biblical). They are only interpreted initially, the first time the file is created. Any modifications to the URL file later on will not be committed. This is because the shortcut is not stored in the file. This is why the file can be modified later on so that it becomes empty, as a 0 byte file and the URL file will appear to be working anyway. The shortcut data is stored in the "Web Document" field as a file property in the NTFS file system. The file merely serves the purpose of pointing to it. You might be able to modify these property fields programmatically, which would supposedly "edit the file". It's a painful exercise just to edit what appears to be a simple text file.
Additionally, once a file name has been used for a URL file, it cannot be reused for new files, no matter what disk or path you save it to. So you have to keep assigning unique file names, never used previously, for each new URL file you create. This has to do with how Internet Explorer caches web content. It remembers what file names have been used already and maps those names to previously defined URL addresses. To reuse a name (or when you run out of ideas for new and unique file names) you have to clear Temporary Internet Files.
Windows 7: %localappdata%\Microsoft\Windows\Temporary Internet Files
Windows 8: %localappdata%\Microsoft\Windows\INetCache
To directly answer your question: yes, it does.
Windows 7 Caches your Filenames and sometimes, as you said, the filenames in specific locations.
Start regedit and search for the following
HKEY_USERS\S-1-5-21-x-x-x-x\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
where S-1-5-21-x-x-x-x is your currently logged in User.
There you can see that most (or all?) files have been cached which you have ever accessed.
Maybe you can also deactivate the MUICaching programatically. Maybe this site helps you: Disable Caching
I had a similar issue, and it turns out the culprit was Firefox.
If by chance your web browser is Firefox, your cache directories may be corrupted.
You can either create a new Profile, or take your chances cleaning things out of C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<profile>\
I've found my desktop .url shortcut contents cached in %LocalAppData%\Microsoft\Windows\Caches.
There are a few (several?) files with filenames like {<SOME_GUID>}.<x>.ver0x<XXXXXXXXXXXXXXXX>.db. Two of them had the .url files cached.
Unfortunately, I've found no information on what they are or how to refresh them. Everybody just deletes them as part of some cache clean-up operation.