 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / March 2006ProcessStartInfo.WorkingDirectory and Mapped Network Drives
Has anyone successfully called the Start() method on a System.Diagnostics.Process object with the object's ProcessStartInfo.WorkingDirectory set to a path on a mapped network drive? For example, if I have "w:" mapped to "\\serverA\share1" and set ProcessStartInfo.WorkingDirectory = "w:\dir1", my calls to Process.Start() always fail with the error "The directory name is invalid". Whereas, if I do the same thing with WorkingDirectory = "c:\dir1", calls to Process.Start() always succeed. Before anyone asks, yes the directory "dir1" does exist on w: and is readable under the user context calling the Process.Start() method. If no one has successfully executed Process.Start() with WorkingDirectory pointing to a mapped network drive, does anyone have any (MS) reference article confirming that this is not possible and perhaps explaining why? Thanks in advance. Just discovered a critical piece of the puzzle... The Start() method fails, as described below, only when running as a Windows Service. When I try the same thing from s straight Console App while logged in as the service account user, Start() succeed. However, when running as a Windows Service it doesn't seem I can set WorkingDirectory to any mapped drives...even though I have confirmed that the mapped drive does exist and is accessible to the service account. So, a refinement of my question should read "Has anyone successfully set ProcessStartInfo.WorkingDirectory to a mapped network drive while running as a Windows Service?" > Has anyone successfully called the Start() method on a > System.Diagnostics.Process object with the object's [quoted text clipped - 15 lines] > > Thanks in advance. When a windows service starts, no one is logged into the computer. Until someone logs in, there are NO mapped drives! So, you will have to use UNC paths (//server/share1/dir1). Bob > Just discovered a critical piece of the puzzle... > [quoted text clipped - 36 lines] >> >> Thanks in advance. Thanks for the reply Bob. However, I have two comments/questions... 1) While running as a Windows Service, I can map a drive and access it like a local drive - it's just ProcessStartInfo.WorkingDirectory fails when I set it to a mapped drive. So, when you say "there are NO mapped drives" I would argue that there are...once you map them. Did I misunderstand your statement? 2) In my code, ProcessStartInfo.WorkingDirectory doesn't like UNC paths either. Have you experienced something different? > When a windows service starts, no one is logged into the computer. Until > someone logs in, there are NO mapped drives! So, you will have to use UNC [quoted text clipped - 41 lines] > >> > >> Thanks in advance. A windows service starts before anyone logs on. At that time, there are no mapped drives. When you log on, you can see w:, but your service has failed by then. Services are designed that way on purpose - all the computer has to do is start up. SQL Server is a great example - you can set it up, put the computer in a closet, and leave it alone and still use SQL from a client machine. Bob > Thanks for the reply Bob. However, I have two comments/questions... > [quoted text clipped - 65 lines] >> >> >> >> Thanks in advance. Bob, With respect, I think you've missed the point of my question and previous comments - perhaps through a miscommunication of my own. I'll attempt to clarify one last time...Here's the scenario: 1) I've written a Windows Service (C# and .NET Framework 2.0). This Windows Service has its properties set such that it runs under the context of a particular user account. For simplicity's sake, assume this user to be the Domain Administrator account (DOMAIN\Administrator). 2) In the service's OnStart() event, the first thing I do is map a network drive by executing the Start() method of a System.Diagnostics.Process object whose ProcessStartInfo object has been configured such that my service essentially executes the following command: "net use w: \\serverA\share1". From this point forward, the mapped network drive "w:" IS available to my service. Bob, while you are correct that by default no drives are automatically mapped when a Windows Service starts, you are incorrect in implying that a service cannot map a network drive or access a mapped drive once the service is running - it can. I'll be glad to send you example code if you would like to try it out for yourself. 3) Now that the drive "w:" is mapped and accessible to my service in a general way (i.e., I can perform a directory listings on "w:", I can write files to "w:", I can read files from "w:", etc.), I create a new Process object. With this new Process object, I'd like to explicitly set its ProcessStartInfo.WorkingDirectory property to a path on "w:" (remember, "w:" IS available to my service at this point in time). 4) When I set the WorkingDirectory to any path on "w:", the call to Start() fails. However, when I set the WorkingDirectory to any path on "c:", the Start() method of the Process object executes just fine. Hence, my problem. Hopefully, I've made it clear that I'm not having trouble with or confused about mapping or accessing a mapped network drive from within a service. I can prove that my service maps the drive and is accessible for things such as directory listings, file creation, etc. Rather, what I seek is an understanding why it seems the ProcessStartInfo.WorkingDirectory doesn't like to be given a path that incorporates a mapped drive when the Process object's Start() method is called from within a service. Make more sense? > A windows service starts before anyone logs on. At that time, there are > no mapped drives. When you log on, you can see w:, but your service has [quoted text clipped - 73 lines] > >> >> > >> >> Thanks in advance. No I understood perfectly. A windows service runs with no users logged on. Mapped drives are attached to logged on users. Ergo, services NEVER see mapped drives. That is your problem. Bob > Bob, > [quoted text clipped - 136 lines] >> >> >> >> >> >> Thanks in advance. Bob, I do appreciate your attempts to be helpful, but you are wrong on two points: 1) You do not "understand [what I've written] perfectly." 2) Services CAN, as I described previously, see mapped drives. For proof, perform the following simplified test (example created using C#, VS2005, and .NET 2.0 Framework)... First, create a new Windows Service with the following in its ServiceBase.OnStart() method: //=========== Begin Code Snippet ============== System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.StartInfo.CreateNoWindow = true; proc.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden; proc.StartInfo.FileName = "net"; proc.StartInfo.Arguments = "use w: \\\\serverA\\share1"; proc.Start(); proc.WaitForExit(); System.IO.StreamWriter sw = new System.IO.StreamWriter("w:\\MappedDriveOutput.txt", false); //note the reference to mapped drive w: sw.AutoFlush = true; System.IO.DirectoryInfo dir = new System.IO.DirectoryInfo("w:"); //again, note the reference to mapped drive w: System.IO.FileSystemInfo[] files = dir.GetFileSystemInfos(); foreach (System.IO.FileSystemInfo info in files) { sw.WriteLine(info.FullName); } sw.Close(); sw.Dispose(); //=========== End Code Snippet ============== Once you have created your service, install it and run under DOMAIN\Administrator user account context (making sure DOMAIN\Administrator has read/write rights to \\serverA\share1). Make sure there are files in share1 on serverA. Start the service. The service shall attempt to map drive w: to \\serverA\share1 as DOMAIN\Administrator, created a file on "w:", and write a directory listing of "w:" to that file before finishing its OnStart() method. If you do not get the same results, let me know where it is failing and what error you are getting and we can try to reconcile. Perhaps there's some subtle difference in our environments, such as O/S version, etc. (I'm running on Win2k3, by the way). Otherwise, if you DO get the appropriate output file, please explain how the service you created was able to read from and write to "w:" if "w:" was not mapped and available to the service? Hopefully, this will move us beyond this sticking point and get back to the question I'm asking about the ProcessStartInfo.WorkingDirectory property not accepting a reference to a mapped drive while running as a service. > No I understood perfectly. A windows service runs with no users logged > on. Mapped drives are attached to logged on users. Ergo, services NEVER see [quoted text clipped - 141 lines] > >> >> >> > >> >> >> Thanks in advance. I am afraid your problem is that by the time you map w: with the net use command, the start process code already tried to access it. You might overcome the problem and achieve what you want by specifying your command as in: @"cmd /c net use w: \\serverA\Share1 && cd /d w:\" and let the default directory where it was for the start process that works. /LM > Bob, > [quoted text clipped - 247 lines] >> >> >> >> >> >> >> >> Thanks in advance. Luc, Thanks for the reply. I'm not having problems with the code example I gave - it works as described. Frustratingly, this thread has strayed far from my original question due to the confusion over whether or not you can map and access network drives from within a service. To get the thread back on track, please consider the following: a) A service starts and maps "w:" (please don't anyone tell me this cannot be done, because it can...see my code example below and everything I've written previously in this thread). b) Assume the service goes to sleep for some period of time (seconds, minutes...it doesn't matter). This will eliminate Luc's suspicion that the drive has not successfully mapped by the time Start() is called on the Process object. c) Upon waking up, assume the service creates two System.Diagnostics.Process objects, the only difference between the two being that the first has it's ProcessStartInfo.WorkingDirectory set to a path on the (local) "c:" drive and the second has its ProcessStartInfo.WorkingDirectory set to a path on the (mapped) "w:" drive. In this case, the process with its WorkingDirectory set to the "c:" drive succeeds in having its Working Directory set, but the process with its WorkingDirectory set to a path on "w:" IGNORES the WorkingDirectory setting and defaults to "C:\Windows". If the same "test" is performed outside of a service, the WorkingDirectory is properly set in both cases. Therefore, I know the WorkingDirectory property itself is not limited to local drives only. It's something specific to when the code runs as a service. (Note: If you're tempted to tell me that it's because you cannot map a drive as a service, save your typing...Re-read all that's been previously written in this thread, run the sample code, and you'll see that you CAN map a drive as a service AND access it.) So, why doesn't ProcessStartInfo.WorkingDirectory seem to like being pointed to a network drive when running as a service? This is the question I'm trying to find an answer/workaround for. Can anyone shed some light (specifically on setting ProcessStartInfo.WorkingDirectory to a mapped drive while running as a service)? > I am afraid your problem is that by the time you map w: with the net use > command, the start process code already tried to access it. You might [quoted text clipped - 258 lines] > >> >> >> >> > >> >> >> >> Thanks in advance. > b) Assume the service goes to sleep for some period of time (seconds, > minutes...it doesn't matter). This will eliminate Luc's suspicion that > the > drive has not successfully mapped by the time Start() is called on the > Process object. That is not what I said. I just said that if your start a process with a command 'net use w:..." you cannot set its default directory (before the create) to w: I know you can map drives in services as I do that too :-) For your last post, I am not sure your drive mappings are automatically inherited to processes you create with a bare CreateProcess from your service. What does a process created like you do (as a sub-process of your service) shows when you pass a simple 'net use' command to show what it knows about mapped drives... /LM Hi Luc, Thanks for the reply (and the confirmation that I'm not the only person in the world mapping drives from within services with success ;-). Regarding Processes created by a service and their ability to inherit the service process's mapped drives...I have confirmed they do. I haven't tested specifically with "net use" as you suggested, but along the same lines, I have tested spawning a Process that launches a custom EXE, who operates on "w:" with success (writing files to "w:", doing a directory on "w:", etc.). So, yes, I have confirmed that the spawned process does inherit the mapped drives of the launching service process. So, back to the question of why can't I set ProcessStartInfo.WorkingDirectory to a path on a mapped drive when spawning processes from a service process? Why does it ignore my setting and default to "c:\windows"? Any other thoughts? > > b) Assume the service goes to sleep for some period of time (seconds, > > minutes...it doesn't matter). This will eliminate Luc's suspicion that [quoted text clipped - 14 lines] > > /LM > So, back to the question of why can't I set > ProcessStartInfo.WorkingDirectory to a path on a mapped drive when > spawning > processes from a service process? Why does it ignore my setting and > default > to "c:\windows"? Any other thoughts? I can only guess here, that during the process creation, there are various phases and that the settings of the default directory occurs before the rest of the process context (as inherited environment and mapped drives) . If the drive is well mapped in the end, you could try to use 'Directory.SetCurrentDirectory(...)' in your OnStart, to set the default directory at a later stage, once the process is fully operational. Or if it is an external program you don't have access to, use the 'cmd /c cd /d MyDir && YourProgram' trick as I suggested in my first post (I responded with that because I saw in my older projects that was what I did). /LM Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.