Is it safe to delete or move files or directories when using Directory.EnumerateFiles?
Something like this:
foreach (var fileName in Directory.EnumerateFiles("Sub"))
File.Delete(fileName);
I know that, in general, you are not supposed to modify what you're enumerating. However, the file system doesn't seem to be following that rule since the code above works.
The same question applies to EnumerateDirectories and EnumerateFileSystemEntries, as well as the equivalent methods of the DirectoryInfo class.
Yes you can safely delete current file during such enumeration (at least on windows). Directory.EnumerateFiles is implemented internally (on windows) via FindFirstFile and FindNextFile winapi calls. So first FindFirstFile is called and on each iterator advance (MoveNext()) - FindNextFile is called. If file was removed between those calls - it's not a problem for that api, FindNextFile will just return next matching file. In your case you delete current file so that nothing is skipped at all. If new file were added in the middle of enumeration - it depends on it's name if it will be included or not. Say you already got files "b.txt" and "c.txt" and then file "a.txt" was added. Such file will not be included using Directory.EnumerateFiles, because it's name is "less" (in some sense) that files already enumerated. Return order is not that simple (depends on filesystem) but you got the idea.
No doubt this isn't possible but i would like to see if anyone has an ingenious suggestion. We have a third party assembly which can output an image stored internally within a bespoke database to file using an internal method 'SaveToFile', an example:
3rdParty.Scripting.ImageManager man = new 3rdParty.Scripting.ImageManager("ref");
3rdParty.Scripting.Image itemImg = man.GetImage(orderNumber);
itemImg.SaveToFile("c:\file.jpg")
ItemImg.SaveToFile has no return type and just creates a bitmap internally and writes that to a filestream. We have absolutely no access to the compiled method.
What i need to do is somehow intercept the filestream and read the bitmap, i know this probably isn't possible but i'm no absolute expert so wanted to see if there is a magical way to do this.
If all else fails i'll save the file then read it back, i just want to avoid saving to disk where i might be able to obtain the data directly and eventually convert that to a base64 string value.
Unfortunately unless the 3rd party library provides a SaveToStream method where you could provide the stream from the outside there's no way to achieve what you are after. You will have to save the contents to a temporary file and then read the contents back.
That's why it's usually best practice when designing a library to provide methods taking Streams as I/O parameters as this would give the consumer the control of whether he wants to save it to a file, memory or network stream.
Is it possible to have protogen output multiple files (one per class) based on a single .proto file?
I'm working with a very large .proto file that outputs approx 200 classes, currently all in a single file. One of the places where I need to use the generated classes is in a highly memory constrained environment (a Windows Phone background agent).
I'd like to be able to only include the necessary classes in the assembly loaded in the constrained environment but can't easily do this when the generated classes are all in a single file. If I could have them outputted to multiple files I could only link in the ones I need in the assembly for the constrained environment.
Is there a way to have protogen output the classes in separate files? I can't see an option for this and am currently only using the umbrella-classname option.
Manually editing the generated file is not an option so if protogen can't do it, is there another commandline tool available which can split up a file containing multiple classes? (To save reinventing the wheel.)
Update
I'm using Google.ProtocolBuffers.dll an inherited decision and not easily changable.
Editing/splitting the .proto file is also not a posibility. (Unless as a custom step.)
We have an option for this in csharp_options, but it's not implemented:
// Whether to generate a single file for everything within the
// .proto file (false), or one file per message (true).
// This option is not currently honored; please log a feature
// request if you really want it.
optional bool multiple_files = 4;
Given that you'd have to remove relevant files and make sure you got all the dependencies right it sounds like it wouldn't actually save you much work over the solution I'd suggest, which is to split your proto file into separate ones You say this is "also not a possibility" but basically that's all I can suggest at the moment - why is it not a possibility?
EDIT: I've just had another idea. You could potentially run the protoc step of protogen (which is now done automatically if you don't specify otherwise) to parse the .proto file into its descriptor. Then load the descriptor in another program, mutate it as you would any other protobuf message (create a builder from it, edit the message, build) and then save the descriptor. You can then use protogen on the remaining descriptor, and generate only the classes you want...
I'm working on a Windows Phone 7 app, and I was wondering whether anyone had a definitive answer on whether or not I have to check if a directory exists before creating one, and what the advantages/disadvantages of doing/not doing so are. As far as I can tell, from stepping through my code, the following two blocks of code work in the same manner:
using (IsolatedStorageFile appStorage = IsolatedStorageFile.GetUserStoreForApplication())
{
//ensure directory exists
String sDirectory = System.IO.Path.GetDirectoryName(sPath);
if (!appStorage.DirectoryExists(sDirectory))
{
appStorage.CreateDirectory(sDirectory);
}
}
and
using (IsolatedStorageFile appStorage = IsolatedStorageFile.GetUserStoreForApplication())
{
//ensure directory exists
String sDirectory = System.IO.Path.GetDirectoryName(sPath);
appStorage.CreateDirectory(sDirectory);
}
Is it safe to use the second block of code? It didn't seem to throw an exception if the directory already existed, and also seemed to leave the contents of the directory alone.
The IsolatedStorageFile.CreateDirectory will call Directory.CreateDirectory internally. The documentation of Directory.CreateDirectory states:
If the directory already exists, this
method does nothing.
In other words, you don't need to check if that directory exists. The method already does that for you.
I suspect that internally CreateDirectrory is doing a check if the directory already exists or is swallowing an exception. Either way, there is probably a small performance benefit to be had from calling DirectoryExists explicitly before hand.
The way to test for sure would be to benchmark performance of the 2 methods with creating a large number of directories. (If you try this, be aware that you can't have more than 16k directories in a parent directory and you can't go more than 18 (I think) directories deep.)
It's better practice to be explicit about what you're doing. I would hope that any other developer who looked at the code would ask you you weren't testing for existence before creating a directory. Especially if this code was called many times. If you test and find no difference in performance, I'd recommend a comment in the code to state this.
I've been reading that the static methods of the File Class are better used to perform small and few tasks on a file like checking to see if it exists and that we should use an instance of the FileInfo Class if we are going to perform many operations on a specific file.
I understand this and can simply use it that way blindly, but I would like to know why is there a difference?
What is it about the way they work that make them suitable for different situations? What is the point of having this two different classes that seem do the same in different ways?
It would be helpful if someone could answer at least one of this questions.
Generally if you are performing a single operation on a file, use the File class. If you are performing multiple operations on the same file, use FileInfo.
The reason to do it this way is because of the security checking done when accessing a file. When you create an instance of FileInfo, the check is only performed once. However, each time you use a static File method the check is performed.
The methods of the File and FileInfo classes are similar, but they differ in that the methods of the File class are static, so you need to pass more parameters than you would for the methods of the FileInfo instance.
You need to do this because it operates on a specific file; for example, the FileInfo.CopyTo() method takes one parameter for the destination path that's used to copy the file, whereas the File.Copy() method takes two parameters for the source path and the destination path."
References
http://aspfree.com/c/a/C-Sharp/A-Look-at-C-Sharp-File-and-FileInfo-Classes/1/
http://intelliott.com/blog/PermaLink,guid,ce9edbdb-6484-47cd-a5d6-63335adae02b.aspx
The File.Exists will perform much faster than a new FileInfo(filePath).Exists - especially over a network and provided the files actually exist. This is because File.Exists will only check for existence of the file, whereas a new FileInfo(filePath).Exists first constructs a FileInfo object, which contains all the properties (dates, size etc) of the file (if it exists).
In my experience with this, even checking for the existence of 10 files over the network is noticeably faster (ie 20ms vs 200ms) by using File.Exists.
File is optimized for one-off operations on a file, FileInfo is optimized around multiple operations on the same file, but in general there isn't that much difference between the different method implementations.
If you want to compare the exact implementations, Use Reflector to look at both classes.
A FileInfo may be needed to deal with Access Control properties. For the rest it is a Static versus Instance choice and you can pick what is convenient.
FileInfo is an instance of a file thus representing the file itself. File is a utility class so can work with any file
FileInfo:
Need to instantiate before using
Contains instance methods
Cache Info about the File and you need to call Refresh every time to get the latest info about the File
File:
No need to instantiate
Contains static methods
Do not cache, so you get latest info every time you use it.
src:
FileInfo
File
Yes, and one of the reason could be is, as Nag said Files is a utility class and hence no instance is required to be created. Same time, as File being utility class, each time require security check.
On other hand FileInfo requires instance to be created, and that point it uses security check. Thus, now performing multiple operation using FileInfo will not invoke security checks.
Recently I faced problem with File.Exist, I hate this function. After than I've used Fileinfo class Exist function then my program works correct.
Actually what happen in development enviornment File.Exist works well but when it goes to live environment this function is blocking the file object due to that reason I am getting the error access denied and not able to use the file.
This is my learning.
I will never used File.Exist method best is to create the object and then use it. Be aware to use static methods.
The major difference between File class and FileInfo class is that
Both members of the File and FileInfo class are decorated with the [System.Security.SecurityCritical] and [System.Security.SecuritySafeCritical] attribute but File class has 'multiple security checks' as compared to FileInfo class (Read Here) and the check is performed each time when you call a static member of the File class.
When you create an instance of FileInfo, the check is performed only once.
Apart from these, other minor differences are that File is a static type class whereas FileInfo is an instance type class.
Therefore to access the members of FileInfo class you need to create an instance whereas in File class you can directly access its members without the need to create an instance.
If you are performing multiple operations on the same file, it can be more efficient to use FileInfo instance methods instead of the corresponding static methods of the File class.
However, File class provides more methods as compared to FileInfo class.
Note: Either the SecurityCriticalAttribute attribute or the SecuritySafeCriticalAttribute attribute must be applied to code for the code to perform security-critical operations.