Using this namespace:
Microsoft.VisualBasic.FileIO;
I am copying a source folder from on our network to the user's computer using this line of code:
FileSystem.CopyDirectory(networkDir.FullName, localDir.FullName, UIOption.AllDialogs, UICancelOption.DoNothing);
This opens up that nice copy window we are all familiar with, which shows:
that my application is not hung up and is thinking.
how long the transfer will take.
Problem is that this window also shows the source and destination locations of the copy. I don't really want the user to see the IP and exact file path where the files are coming from.
I would like to avoid creating a big recursive foreach loop to make a directory copier, on top of having to provide an active UI that shows that the program is thinking. Are there any good workarounds or other solutions to achieve a directory copy without the source location being made public?
source location being made public
Do you control the source being downloaded from? If it's from a webserver you could make the whole thing ephemeral, and even use a hosts file entry to obfuscate the IP:
"Downloading from http://daves.server.honest/downloads/onetime/23i23i34248723084r/dir.zip"
Could be essentially useless to the 2nd person who tries to use the path.
Sadly if you're on a network drive rather than a webserver, your options are slightly more limited since it all has to be 'real' :/
Related
I know there are a bunch of these questions already but none of the ones I found depict the scenario I have.
So what I want to do is to
move a directory via Directory.Move. Both source and destination are on a file server in the same network so both paths are network paths (starting with \\SERVER rather than a drive letter).
The application that‘s supposed to do that gives me an „UnauthorizedException: Access is denied“. Because it‘s confidential I can‘t show the log or code.
But I tried to reproduce it by simply calling Directory.Move via PowerShell ([System.IO.Directory]::Move()). There I receive the same message. Access to path X is denied. Nothing more.
This error appears with any user context. An admin, an admin with „run as admin“, the user of the application and the user of the application with „run as admin“.
Manually moving these directories works without a problem.
Creating a directory with Directory.CreateDirectory works too. But moving the newly created Directory results in the same error.
Executing these commands on the file server works just fine if using the local path. Using the network path (still on the actual fileserver, though) results again in the Acces is denied error.
Could it be, that the issue lies within the path rather than the directory? The permissions are all correct and set (as said, manual operations work). Are there any workarounds?
I really don‘t know what to do. I‘m the only developer at this company and the rest are network engineers and can‘t help
me either.
There are a number of things that could be causing it to deny access and it would be hard to point you in the right direction without seeing your code. But here are 2 scenarios that might help you.
Scenario 1 - The filepath you are using is in the wrong format, Usually I have had a access denied because the format of the network filepath was actually wrong. I would recommend looking up examples of how you should pass the filepath. Also have a talk with your network engineers and ask them about the rights that have been setup for that filepath.
Scenario 2 - You might be passing a filepath when you also need to specify a name. Now I dont have all the details but I also had issues in the past using the Directory.Move function where I actually had to specify a filename to move it to. You do this by just adding the file and extension to the end of the target path to copy to.
If you could post some more information I might be able to point you in the right direction but this is what I can think of for now. I hope this works for you or atleast brings you closer to an answer. Good luck!
*Edit: It looks like I am wrong on the scenarios, Have a look at this link Can you move a file/folder across a network share in .NET?
You will have to first manually create the filepath and then copy all the files into the new filepath you have created. It seems like Directory.Move has problems when different machines are used.
I'm trying to create software that will add a computer to an Active Directory domain. One criteria I need to meet is the machine must be added to the proper OU. In order to do this I have a set list of site locations with addresses (this is how we determine OU). This list is currently in the form of an ACCDB file, and I want to include this within the application as the Access list will not be changed.
Everything I see wants the DB file to be connected to in a different location such as server or on the local machine. My preference is to use the DB file as a reference or something inside the program's .exe file itself. I may be missing something horribly obvious, but it's been messing with me for a couple days so I'm reaching out for help.
To clarify, this software MUST be self contained (no installer). It must also be able to determine the proper OU to join to the domain (no access to shares until the PC joins the domain). It must also be user-friendly enough to avoid mistakes, meaning I want to avoid copying distributing multiple files that must go to a correct location. This is why I want to embed the ACCDB file into the application for on the fly use.
Things get much easier because this is static data. You don't have to worry about persisting this data, reclaiming changes into your program, or users accidentally deleting something, etc. You will be able to just use an embedded resource in your application. In the link, follow the examples using the image file. Text file examples will corrupt your database.
However, there is still a trick to doing this. The problem is the Access engine included with Windows will not be able to open the database as a resource, and so you will need to save this file to the local hard drive. The good news is its not as bad as it seems, because your program can do this as needed, and make sure it's right, rather than asking the user to put a file in a specific place.
As for where to put the file when you extract it... the safest and best place is the Application Data folder. You can easily get the path for this folder by checking the results of this call:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This will give you a path where standard privilege users do have write access, no matter which user.
In summary:
Embed the ACCDB as a resource.
When your program runs, get the Application Data path using the Environment object.
Open a FileStream for writing to a file based on the path from #2
Open the embedded resource as a Stream object in C#
Copy the stream from #4 to the stream from #3. Make sure to use a mechanism intended for binary data, rather than text.
Close/Dispose your streams, so no locks remain on the file. This is as simple as putting using blocks in the right places.
Open a normal Access connection to the file you just made, using any of the thousands of tutorials or examples available on the web as a guide.
In this way, you only need to distribute the final .exe file, and users won't need any special permissions to use the database. You don't have to worry if a user deletes your file; it's still embedded in the application, which will recreate it if needed every time it starts up.
The downside is a clever user may be able to manipulate the database to end up in an undesirable OU. If you need to worry about this, you should consider having the program check a web service, rather than using embedded data. Anything you embed can ultimately be altered by an end user. A web service is also nice because you can update your mapping data as your organization evolves, without needing to rebuild or redistribute the program.
I work for an IT company where we all carry around flash drives that have our most used programs on them.In my spare time I am hoping to create a "main menu" item that is kind of a fun and convenient way to access these files. I am working on creating this using Visual Studio 2013 and using visual C# windows forms. I have come across a snag however that I can't seem to find a workaround for. I am by no means fluent in C#, but I need to have a button on the windows form open a file without specifying what drive it comes from. I understand that I have to specify a path, but as these will be stored on the flash drives of myself and my coworkers I cannot foresee that the path will always begin with E:. Depending on what USB slot the drive is plugged into it could be N: or F: or the like. I have provided an example below:
Using what I currently know I am opening files using this line of code:
System.Diagnostics.Process.Start("C:/Users/Myname/Desktop/Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
Is there any way possible I can have the file open simply from
System.Diagnostics.Process.Start("Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
or something of that nature?
Thanks in advance.
There must have been some mis-communication when I asked my question previously. what I am looking to do is open an executable file via a button click on the windows form using a relative path. I am not able to specify the absolute path because the application will be run from a flash drive and therefore will change depending on what USB slot it is currently inserted into.
What I am hoping to accomplish is insert a line of code that will allow me to open an executable file that is located in the \bin\debug folder along with the application itself. I have a picture for clarification but apparently do not have enough reputation to post it. Thank you and sorry for the earlier confusion.
Usually you can just use Environment.GetFolderPath (MSDN) to give you what you need. It doesn't do absolutely everything, but if you need Desktop and the like, that is plenty.
Depending on the target version of .Net, the SpecialFolders exposed are not all there. It may turn out that you need more than they provide, but in your case it doesn't sound like it.
If there is more you need that is not covered in the default, check out this project. I'm sure there are others like it, but it does a little more than the default BCL version, using the API directly. It is at least something to read and learn (and translate from vb.. use an online translator, very quick). I haven't looked at it, but it seems like you are learning this c#/.net thingy, so it might be helpful
This article is about accessing Windows special folders.
These folders include your “Favorites”, “Cookies”, system libraries and the like.
Here is code, including a large number of constant definitions, plus documentation,
allowing access to and creation of these folders.
i am trying to make a code which takes an image from a file path which i type in manually.
here is my code:
pieceImage = Image.FromFile(#"O:\Projects\imagename.png");
This code is saved on my USB flash drive.
However, whenever i run this code on a different computer, the path is different (obviously) and doesn't necessarily start with O:\ but something else, for example F:.
What can i use so that the path will change accordingly to the computer on which it runs? many thanks in advance.
You could get the drive letter based on the drive name, then build the Path to the file based on that (so only use the relative path from the root of the drive, no letter). See the DriveInfo class on MSDN and this question for a practical example of usage.
Of course, if the image is not on the USB drive, you will need to be more creative. But then I would recommand a different approach all the same, because there might be a design flaw in all this.
Assuming your program is in directory /Program/, include all images under your /Program/ directory, such as /Program/Images/. That way the images will be available no matter where the program is run.
I am by no means a programmer but currently am wondering if an application creates a temp file that windows names. For example the file it creates is tmp001, is there a way i can take that name tmp001 and ask windows to give me the next temp file it would create before it creates it.
Thanks,
Mike
There is no direct means to get to know the next temporary filename to be created.
For example, programmers use the System.IO.Path.GetTempFileName method, but one can add application-specific prefixes or suffixes in order to make it easier for the application to find its newly created files.
One can even choose to save this temporary file elsewhere than the system Temp folder.
You would need to define a "temp file" much more explicitly in order to answer this question with a "Yes". The problem is that a "temp file" is just something not meant to be kept. It could exist anywhere on the system and be created by a user, application, or service. This would make it nearly (or actually) impossible to answer your question with a "Yes".
If you constrain the definition of a temp file to just the files in the official temp folder (or a subfolder), you still have a problem if you're trying to catch names not generated by windows. Any app could produce a particularly named temp file in that folder, without Windows caring.
If you further constrain the definition to be only those files named by Windows, you might be able to get somewhere. But, does that really meet your needs?
After all of that, maybe it would be better to describe the problem you're trying to solve. There may be a much better (workable) solution that would address the issue.
Typically applications use the Win32 API GetTempFileName to get the temporary directory.
The process of how the temp file is generated is described there.
I'm not sure why you want this info, but perhaps you could for example register for directory changes via a Win32 API like ReadDirectoryChangesW or by using a mini filter driver.
This kind of code just cannot work reliably on a multi-tasking operating system. Another thread in another process might pre-empt yours and claim the file name you are hoping to create.
This is otherwise easy enough to work around, just name your own files instead of relying on Windows doing it for you. Do so in the AppData folder so you'll minimize the risk of another process messing it up.