We Keep Coding

Create a folder without read-only using c# [duplicate]

I was successfully able to remove read only attribute on a file using the following code snippet:
In main.cs
FileSystemInfo[] sqlParentFileSystemInfo = dirInfo.GetFileSystemInfos();
foreach (var childFolderOrFile in sqlParentFileSystemInfo)
{
RemoveReadOnlyFlag(childFolderOrFile);
}
private static void RemoveReadOnlyFlag(FileSystemInfo fileSystemInfo)
{
fileSystemInfo.Attributes = FileAttributes.Normal;
var di = fileSystemInfo as DirectoryInfo;
if (di != null)
{
foreach (var dirInfo in di.GetFileSystemInfos())
RemoveReadOnlyFlag(dirInfo);
}
}
Unfortunately, this doesn't work on the folders. After running the code, when I go to the folder, right click and do properties, here's what I see:
The read only flag is still checked although it removed it from files underneath it. This causes a process to fail deleting this folder. When I manually remove the flag and rerun the process (a bat file), it's able to delete the file (so I know this is not an issue with the bat file)
How do I remove this flag in C#?

You could also do something like the following to recursively clear readonly (and archive, etc.) for all directories and files within a specified parent directory:
private void ClearReadOnly(DirectoryInfo parentDirectory)
{
if(parentDirectory != null)
{
parentDirectory.Attributes = FileAttributes.Normal;
foreach (FileInfo fi in parentDirectory.GetFiles())
{
fi.Attributes = FileAttributes.Normal;
}
foreach (DirectoryInfo di in parentDirectory.GetDirectories())
{
ClearReadOnly(di);
}
}
}
You can therefore call this like so:
public void Main()
{
DirectoryInfo parentDirectoryInfo = new DirectoryInfo(#"c:\test");
ClearReadOnly(parentDirectoryInfo);
}

Try DirectoryInfo instead of FileInfo
DirectoryInfo di = new DirectoryInfo(#"c:\temp\content");
di.Attributes = FileAttributes.Normal;
To clean up attrbutes on files-
foreach (string fileName in System.IO.Directory.GetFiles(#"c:\temp\content"))
{
System.IO.FileInfo fileInfo = new System.IO.FileInfo(fileName);
fileInfo.Attributes = FileAttributes.Normal;
}

The dialog just works in a fairly bizarre way. It always shows up the way you see it in your screen shot, whatever the state of the ReadOnly attribute. The checkbox is in the 'indetermined' state. You have to click it and either clear or check it to make it perform its action. And in spite of the prompt text (but not the hint next to the checkbox), it only changes the ReadOnly attribute on the files in the directory, not the directory itself.
Use the attrib command line command to see what is really going on. In all likelihood, your code fails because the directory contains files that have their ReadOnly attribute set. You'll have to iterate them.

The read-only flag on directories in Windows is actually a misnomer. The folder does not use the read-only flag. The issue is going to be with the customization. The flag is used by Windows to identify that there are customizations on the folder.
This is an old post, with an issue that is sunsetting, but, figured people might still run into it, as it is pretty annoying when you hit it.
Microsoft's Explanation

IEnumerable / Lambda solution for recursively removing readonly attribute from directories and files:
new DirectoryInfo(#"some\test\path").GetDirectories("*", SearchOption.AllDirectories).ToList().ForEach(
di => {
di.Attributes &= ~FileAttributes.ReadOnly;
di.GetFiles("*", SearchOption.TopDirectoryOnly).ToList().ForEach(fi => fi.IsReadOnly = false);
}
);

Set the Attributes property on the original dirInfo:
dirInfo.Attributes = FileAttributes.Normal;
FileSystemInfo[] sqlParentFileSystemInfo = dirInfo.GetFileSystemInfos();
foreach (var childFolderOrFile in sqlParentFileSystemInfo)
{
RemoveReadOnlyFlag(childFolderOrFile);
}

Just in case any one happens across this later...
ALL of the other answers posted before mine are either wrong or use unnecessary recursion.
First of all the "Read Only" check box in the property dialog of windows always has the tri-state marker for folders. This is because the folder itself is not read only but the files inside can be.
If you want to set/unset read only flag for ALL files. you can do it simply as follows:
void SetReadOnlyFlagForAllFiles(DirectoryInfo directory, bool isReadOnly)
{
// Iterate over ALL files using "*" wildcard and choosing to search all directories.
foreach(FileInfo File in directory.GetFiles("*", SearchOption.All.Directories))
{
// Set flag.
File.IsReadOnly = isReadOnly;
}
}

I see that #DotnetDude said in comments that solutions of guys don't work. To my mind it is happens because guys don't mentioned that need to use File.SetAttributes method to apply new attributes.

This may or may not be directly related, but the root issue in your case may be caused by the underlying files. For example, I ran into this issue trying to delete a directory:
System.IO.Directory.Delete(someDirectory, true)
This results in "Access to the path 'blah' is denied". To resolve this underlying problem, I removed the read-only attribute on sub-files and was then able to remove the parent directory. In my case, I was using powershell, so you can use the .NET equivalent.
dir -r $PrePackageDirectory |% {if ($_.PSIsContainer -ne $true){$_.IsReadOnly = $false}}

Shell("net share sharefolder=c:\sharefolder/GRANT:Everyone,FULL")
Shell("net share sharefolder= c:\sharefolder/G:Everyone:F /SPEC B")
Shell("Icacls C:\sharefolder/grant Everyone:F /inheritance:e /T")
Shell("attrib -r +s C:\\sharefolder\*.* /s /d", AppWinStyle.Hide)
this code is working for me.. to share a folder to every one with read and write permission

Microsoft Diagnostics Runtime crash.dmp analysis (C#)

I'm trying to read in a crash.dmp using the functionality in Microsoft.Diagnostics.Runtime .NET componenet (also known as ClrMD).
I have a crash.dmp in a known location (in a string called pathToFile) so that's not the issue. The rest of the code looks like this.
DataTarget dataTarget = DataTarget.LoadCrashDump(pathToFile);
ClrInfo clrInfo = dataTarget.ClrVersions[0];
string dacLocation = clrInfo.TryGetDacLocation();
When testing this code, I get the following error in the command window:
Error processing directory: System.ArgumentOutOfRangeException. Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index.
I'm assuming it's something to do with the ClrVersions[0] bit but can't for the life of me pin it down.
Any help would be appreciated.
Current Status
When running the following command (which fails)
ClrRuntime rt = dataTarget.CreateRuntime("path\to\mscordawks.dll");
I receive the following error in cmd
mismatched architecture between this process and the dac
Cheers
Anyone?

If the TryGetDacLocation succeeded then you should be able to do
ClrRuntime rt = dataTarget.CreateRuntime(dacLocation);
so you get the correct dacLocation.
Was the dump you are analysing generated on same machine where you are analysing it?
Also what are the bitnesses of the process the dump was generated from, the process in which the CLRMD code is running and the debugger utility used to generate the dump?
Generally you want to be matching the bitnesses all round (x86/x64).
Doug

I was having the same issue reading a dump file generated on the same computer. There were two problems, first bitness (should have been 64, was running in 32) and the second harder problem that the proper DLL could not be located. To fix the second problem I created a method that tries all of the properly named DLLs it can find:
private static ClrRuntime GetRuntime(DataTarget target)
{
ClrInfo version = target.ClrVersions[0];
string dacLocation = version.TryGetDacLocation();
// If we don't have the dac installed, we will use the long-name dac in the same folder.
if (!string.IsNullOrEmpty(dacLocation))
dacLocation = version.DacInfo.FileName;
try // try the one it should be
{
return target.CreateRuntime(dacLocation);
}
catch (Exception e)
{
}
// can't find the one it should be, try'em all
string fileName = "mscordacwks.dll";
string[] searchLocations = new[]
{
#"C:\Windows\Microsoft.NET\",
#"C:\Windows\winsxs\"
};
foreach (string searchLocation in searchLocations)
{
foreach (string file in Directory.GetFiles(searchLocation, fileName, SearchOption.AllDirectories))
{
try
{
return target.CreateRuntime(file);
}
catch (Exception e)
{
}
}
}
throw new Exception("No found valid runtimes");
}

I followed this artificial to get the mscordacwks.dll when dealing with platform differences between where the dmp file was taken and the machine doing the analysis.
http://chentiangemalc.wordpress.com/2014/04/16/obtaining-correct-mscordacwks-dll-for-net-windbging/#comment-3380
and followed the steps including renaming the file to include the architecture and version information.
After that I just http://chentiangemalc.wordpress.com/2014/04/16/obtaining-correct-mscordacwks-dll-for-net-windbging/#comment-3380ut the full path of the file as dacLocation in the script.
After that it worked!
I suspect that putting it on the path could be made to work.

Unable to launch shortcut (lnk) files from 32-bit C# application when the full path resolves to a 64-bit directory

I'm trying to launch programs in the Start Menu from a C# application, and nearly all of the items in the Start Menu are shortcut (lnk) files. When using Process.Start to launch these files, I found that I was getting "The system cannot find the path specified" error if the full path of the lnk file pointed to the C:\Program Files directory. I did some research with File System Redirection in Windows, so I tried disabling it, but I'm still getting the same error:
// disable file system redirection:
IntPtr ptr = new IntPtr();
bool isWow64FsRedirectionDisabled = Wow64DisableWow64FsRedirection(ref ptr);
// run the file:
System.Diagnostics.Process.Start("c:\\splitter.lnk");
This returns "The system cannot find the path specified." However, if I launch c:\splitter.lnk from the Start > Run dialog box, the program runs just fine. You can reproduce this issue on any 64-bit machine by creating a shortcut for any 64-bit app, placing it on the C drive, and attempting to run it using the code above.
Is there a better way to launch .lnk files to avoid this problem? Or am I not disabling file redirection properly?
EDIT: I also tried setting UseShellExecute to true to have the operating system run the file, but that still fails, which is interesting because running the same path from the Start > Run dialog box works just fine:
Process process = new Process();
process.StartInfo.UseShellExecute = true;
process.StartInfo.FileName = "c:\\splitter.lnk";
process.Start();
EDIT 2: I figured that instead of trying to launch the LNK file directly, I would get the target for it, and then run the target. I tried using How to resolve a .lnk in c# and How to follow a .lnk file programmatically, but both methods return the full path as C:\Program Files (x86)\Splitter.exe instead of the actual path of C:\Program Files\Splitter.exe.
Perhaps I can use one of the above methods to get the target of the LNK file. Then I can see if the target contains Program Files (x86). If it does, replace it with Program Files and check if the file exists. If it exists in Program Files, run that. If not, run the file from the Program Files (x86) location. This would be a messy workaround, but I don't know what else to try at this point. Any suggestions would be appreciated.

I was able to provide a workaround for this issue by using Sam Saffron's example script at How to resolve a .lnk in c#. I modified the ResolveShortcut function to the following:
public static string ResolveShortcut(string filename)
{
// this gets the full path from a shortcut (.lnk file).
ShellLink link = new ShellLink();
((IPersistFile)link).Load(filename, STGM_READ);
StringBuilder sb = new StringBuilder(MAX_PATH);
WIN32_FIND_DATAW data = new WIN32_FIND_DATAW();
((IShellLinkW)link).GetPath(sb, sb.Capacity, out data, 0);
string final_string = sb.ToString();
if (final_string.Length == 0)
final_string = filename;
// If the the shortcut's target resolves to the Program Files or System32 directory, and the user is on a
// 64-bit machine, the final string may actually point to C:\Program Files (x86) or C:\Windows\SYSWOW64.
// This is due to File System Redirection in Windows -- http://msdn.microsoft.com/en-us/library/aa365743%28VS.85%29.aspx.
// Unfortunately the solution there doesn't appear to work for 32-bit apps on 64-bit machines.
// We will provide a workaround here:
string new_path = Validate_Shortcut_Path(final_string, "SysWOW64", "System32");
if (File.Exists(new_path) == true && File.Exists(final_string) == false)
{
// the file is actually stored in System32 instead of SysWOW64. Let's update it.
final_string = new_path;
}
new_path = Validate_Shortcut_Path(final_string, "Program Files (x86)", "Program Files");
if (File.Exists(new_path) == true && File.Exists(final_string) == false)
{
// the file is actually stored in Program Files instead of Program Files (x86). Let's update it.
final_string = new_path;
}
// the lnk may incorrectly resolve to the C:\Windows\Installer directory. Check for this.
if (final_string.ToLower().IndexOf("windows\\installer") > -1)
final_string = filename;
if (File.Exists(final_string))
return final_string;
else
return filename;
}
public static string Validate_Shortcut_Path(string final_string, string find_what, string replace_with)
{
string final_string_lower = final_string.ToLower();
string find_what_lower = find_what.ToLower();
int find_value = final_string_lower.IndexOf(find_what_lower);
if (find_value > -1)
{
// the shortcut resolved to the find_what directory, which can be SysWOW64 or Program Files (x86),
// but this may not be correct. Let's check by replacing it with another value.
string new_string = final_string.Substring(0, find_value) + replace_with + final_string.Substring(find_value + find_what.Length);
if (File.Exists(new_string) == true && File.Exists(final_string) == false)
{
// the file is actually stored at a different location. Let's update it.
final_string = new_string;
}
}
return final_string;
}
If anyone is aware of a better way to do this, I am open to ideas. Otherwise I will use this method and accept this workaround as the answer.

Can't rename directory in C# but manually

I'm using Directory.Move(oldDir, newDir) to rename a directory. Every now and then I get a IOException saying "Access to the path "oldDir" is denied". However if I right click the directory in the explorer I can rename it without any issues. How's that and how can I get it to work?
EDIT
The program is still running, I get the exception and can rename it manually while my cursor is paused on the breakpoint. I also tried setting a breakpoint at Directory.Move, successfully renamed the directory in explorer (and back again), stepped over Directory.Move and ended up in the catch (IOException) again. So I don't see why my program should lock the directory at all. There must be something else.
Any ideas?
EDIT 2
Here is my code
public bool Copy()
{
string destPathRelease = ThisUser.DestPath + "\\Release";
if (Directory.Exists(destPathRelease))
{
try
{
string newPath = ThisUser.DestPath + '\\' + (string.IsNullOrEmpty(currBuildLabel) ? ("Release" + '_' + DateTime.Now.ToString("yyyyMMdd_HHmmss")) : currBranchName) + '.' + currBuildLabel;
Directory.Move(destPathRelease, newPath);
catch (IOException)
{
// Breakpoint
}
}
}
}
As you can see I just entered the method. I never touched the directory in my program before. Is there another way to rename a directory?

Without seeing more code I'd say your application is locking a file within the directory, you can see what is accessing the directory using Process explorer
from the intro to process explorer:
Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.
It might also be worth making sure nothing else is copying files from/to that directory - e.g. dropbox. I had an issue recently where visual studio would stop debugging because of a file lock - in the end it was indexing on the drive which was temporarily locking the file. Process explorer only partially helped in that it showed 'system' had the file lock and not another application.

You need to check the User that is running the .net application. It don't have the right permission to execute the rename.
This is:
the user running the application pool for web applications
the logged application for console/winforms application
the configured user for services or scheduled tasks

If the parent directory of your destination directory does not exist, The Directory.Move operation with fail. I've just been trying to figure out something loosely similar to this.

This is the safest method to rename a directory in the C# .NET Core with cross-platform.
/// <summary>
/// Renames a folder name
/// </summary>
/// <param name="directory">The full directory of the folder</param>
/// <param name="newFolderName">New name of the folder</param>
/// <returns>Returns true if rename is successfull</returns>
public static bool RenameFolder(string directory, string newFolderName)
{
try
{
if (string.IsNullOrWhiteSpace(directory) ||
string.IsNullOrWhiteSpace(newFolderName))
{
return false;
}
var oldDirectory = new DirectoryInfo(directory);
if (!oldDirectory.Exists)
{
return false;
}
if (string.Equals(oldDirectory.Name, newFolderName, StringComparison.OrdinalIgnoreCase))
{
//new folder name is the same with the old one.
return false;
}
string newDirectory;
if (oldDirectory.Parent == null)
{
//root directory
newDirectory = Path.Combine(directory, newFolderName);
}
else
{
newDirectory = Path.Combine(oldDirectory.Parent.FullName, newFolderName);
}
if (Directory.Exists(newDirectory))
{
//target directory already exists
return false;
}
oldDirectory.MoveTo(newDirectory);
return true;
}
catch
{
//ignored
return false;
}
}

Running an app using process.start returns different value than running it manually

I'm running a tool that samples the HW PCI for a specific value (I didn't write it).
When I run it from the command prompt, it returns one exit code (the correct one) but when I run it from another application using Process.Start, it returns another exit code.
Is there a difference between running an application directly or via Process.Start?
Do you know of a simple workaround for this issue?

As stated in Hassan's answer (which solved my similar issue), the exit code returned from Process.Start() is affected by the location of the executable, in particular which directory it is located in. Here's the code I used:
string yourExe = "C\\Program Files\\Your Directory\\YourExe.exe";
string currentDir = Directory.GetCurrentDirectory();
string yourExeDir = "C\\Program Files\\Your Directory";
try
{
Directory.SetCurrentDirectory(yourExeDir);
}
catch (DirectoryNotFoundExeption dnfe)
{
MessageBox.Show("The specified directory does not exist. " + dnfe.Message);
}
if (!File.Exists(yourExe))
{
MessageBox.Show("Can't find yourExe");
}
else
{
Process.Start(yourExe);
}
try
{
//Set the current directory.
Directory.SetCurrentDirectory(currentDir);
}
catch (DirectoryNotFoundException dnfe)
{
MessageBox.Show("The specified directory does not exist. " + dnfe.Message);
}
This switches the current working directory to the directory where the .exe is located, runs it, and then switches back to whatever your previous working directory was.

If you want the same result from Process.Start(), you have to execute your application on
the same working directory as your command line.