Is it possible to create a file on a disk which is full??
Does creation of the file take any space??
Basically I am seeing a case where C# has created but failed to write anything whhich I think points to a full disk.
Does anyone know whether creating a file on a full disk will fail or not??
This wa done using c# o Windw xSerevr- The log file was also written to the same drive
Creating (empty) files should still be possible in most cases. The MFT is a separate part of the volume which won't get used for file data.
It should even be possible to store small amounts of data without needing more than the file entry in the MFT. NTFS can store streams as "resident data" in the stream descriptor which doesn't need any additional space, but only works for very small files.
I think your issue is another problem, though. It may be that you have permissions to create a file but not to write anything to it. You might want to check the ACLs of the location where you're trying to write.
Related
I'm working in c#, and looking for a way to create a path to a directory that will map to an IO.Stream instead of to the actual file system.
I want to be able to "save" files to that path, manipulate the content or file names, and then save them from that path to a regular file in the file system.
I know I can use a temporary file, but I would rather use the memory for both security and performance.
This kind of thing exists, according to this answer, in Java, using the FileSystemProvider class. I'm looking for a way to do it in c#.
I've tried every search I could think of and came up only with the java answer and suggestions to use Temporary files.
Is it even possible using .net?
Basically, I'm looking for a way to enable saving files directly to memory as if they where saved into the file system.
so, for instance, if I had a 3rd party class that exposes a save method (save(string fullPath)), or something like the SmtpServer.Send(MyMsg) in this question, i could choose that path and save it into the memory stream instead of onto the drive. (the main thing here is that I want to provide a path that will lead directly to a memory stream).
.NET doesn't have an abstraction layer over the host OS's file system. So unless you can build your own for use in custom code, and you need to have 3rd party libraries covered, there are just two workable optilns:
Use streams and avoid any APIs working with file names.
Build a virtual file system plugged into your host OS's storage architecture; however, the effort needed versus benefits is highly questionable.
I went through a similar situation lately, and there is no out of the box solution in .NET for doing that although I used a workaround which was efficient and safe for me.
Using Ionic.Zip Nuget package you can create a whole directory with a complex structure as a stream in memory and although it will be created as a zip file, you can extract it as a stream or even send the zip file as a stream.
using (var zip = new Ionic.Zip.ZipFile())
{
zip.AddEntry($"file1.json", new MemoryStream(Encoding.UTF8.GetBytes(someJsonContent)));
for (int i = 0; i < 4; i++)
{
zip.AddEntry($"{myDir}/{i}.json", new MemoryStream(Encoding.UTF8.GetBytes(anotherJsonContent)));
}
}
And here is how to extract a zip file as a stream using Ionic.Zip
As we all know that we can not get the full path of the file using File Upload control, we will follow the process for saving the file in to our application by creating a folder and by getting that folder path as follows
Server.MapPath
But i am having a scenario to select 1200 excel files, not at a time. I will select each and every excel file and read the requied content from that excel and saving the information to Database. While doing this i am saving the files to the Application Folder by creating a folder Excel. As i am having 1200 files all these files will be saved in to this folder after each and every run.
Is it the correct method to follow or not I don't know
I am looking for an alternative solution rather than saving the file to folder. I would like to save the full path of file temporarily until the process was executed.
So can any tell me the best way as per my requirement.
Grrbrr404 is correct. You can perfectly take the byte [] from the FileUpload.PostedFile and save it to the database directly without using the intermediate folder. You could store the file name with extension on a separate column so you know how to stream it later, in case you need to.
The debate of whether it's good or bad to store these things on the database itself or on the filesystem is very heated. I don't think either approach is best over the other; you'll have to look at your resources and your particular situation and make the appropriate decision. Search for "Store images on database or filesystem" in here or Google and you'll see what I mean.
See this one, for example.
Say you have a method or property on a third party sealed component that expects a file name. You do not have the source for the third party component. You want that component to do what it's supposed to do (read only) on a file you have, but your file is encrypted on disk and you only want the decrypted version in memory so it cannot be easily copied in its plain form.
Is it possible to create a wrapper or some other approach to trick the component to think it's reading from a file when it's actually reading from a MemoryStream? Or is it totally impossible? Can it be done outside .NET in native Windows code?
Thanks
You can't do that the way that you are proposing, no. My recommendation would be to use the Encrypting Filesystem functionality built into windows. That way the file is stored in encrypted form on disk, but is available via the normal IO methods to the application (provided that the account that is running the application has access to the file).
Can it read from "CON" as input (like many text utilities grep/findstr, more,...)? In this case you can try to redirect input/output stream and feed results thata way.
Is it possible to create a wrapper or some other approach to trick the
component to think it's reading from a file when it's actually reading
from a MemoryStream?
No, sorry. You will have to decrypt the file into a temporary file and then pass this temporary file to the plugin. Once it finishes its work delete the temporary file.
This short answer is if a component is expecting a filename e.g. a string you can not parse it a memory stream.
However if the file is encrypted with Encrypting File System (EFS) or something native to Windows it may be able to decrypt the file without knowing the file is encrypted.
These might help:
http://en.wikipedia.org/wiki/Encrypting_File_System
http://en.wikipedia.org/wiki/BitLocker_Drive_Encryption
You could have a look at Dokan. I haven't tried it, but it's a way of creating a virtual file system in .Net.
You can create an in-memory disk drive (either in code or by using third-party application) and put a file there. Another approach is to implement virtual file system and handle all file requests. Both approaches are possible for example using our Virtual Storage products.
Also, I don't know about .NET in particular, but in Windows you can hook API functions and substitute certain operations (including file operations). There even exist components for this, but, again, I don't know if they offer their functionality for .NET.
Given the path of a string i want to wipe out the contents of a file. The natural way I thought (which maybe incorrect) was to open a FileStream to the file and write gibberish (random data perhaps taken from a RNGCryptoServiceProvider) to it. And then perhaps do this several times and then delete the file.
My problem is that while this may look logically correct, i read up on another blog that Windows might actually choose to write the file to a different place in the hard disk.
Is that the case in Windows Mobile? Will this actually be a problem? Does this writing to a different location in the hard disk apply to even flash based (SD etc) cards ?
I've not personally done this, but you will probably need to use the low-level FLASH driver IOCTLs to do this correctly.
http://msdn.microsoft.com/en-us/library/aa927166.aspx
I think IOCTL_FMD_RAW_WRITE_BLOCKS looks particularly useful.
-PaulH
Another possibility that may work would be to erase the file normally, then use the defragment APIs to wipe ALL of the freespace on your flash. Since you're wiping everything, it won't be necessary to know exactly where on the disk your file was. But, this will wear out your flash drive more quickly. The C# method is detailed in this blog post: http://blogs.msdn.com/b/jeffrey_wall/archive/2004/09/13/229137.aspx
I am writing a client windows app which will allow files and respective metadata to be uploaded to a server. For example gear.stl (original file) and gear.stl.xml (metadata). I am trying to figure out the correct protcol to use to transfer the files.
I was thinking about using ftp since it is widely used and a proven method to transfer files, except that I would have to transfer 2 files for every actual file (.stl and .stl.xml). However, another thought had also crossed my mind ... What if I create an object and wrap the file, metadata and the directory I needed to tranfer it to, serialize the object and then submit a request to a webservice, to transfer the file.
Original file size would range from 100k to 10MB. Metadata size would probably be less than 200k
The webservice call seems like an easier process to me to deserialize the object and distribute the file and respective metadata accordingly. However I'm not sure if this is a sound idea or if there is a better way to transfer this data other than the two methods I have mentioned.
If someone can point me in the right direction it would be much appreciated.
You could wrap it in a zip file like the "new" office document format does. You might even be able to use their classes to package it all up.
Edit:
Take a look at the System.IO.Packaging.Package class. It seems to be what you need. This class resides in the WindowsBase.dll assembly and became available in .NET 3.0.
PS: Remember that even though it is a zip file, it doesn't need to be compressed. If you have very large files, it may be better to keep them uncompressed. It all depends on how they're going to be used and if the transport size is an issue.