I have a memory stream that contains a PDF file.
Is it possible to view the PDF without saving it to the hard disk ? Process.Start() only takes a path and not a stream.
Thank you
Only by implementing your own pseudo-file system in C#, somehow mounting this as a disk in Windows, and having it intercept the file open and stream the contents of your MemoryStream. Absolutely 100% certainly not worth the effort.
You can create a RAM drive and write the stream to it, this way you are still keeping it all in ram (assuming the disk operations are what worries you).
Sure, this is certainly possible. Just not via Process Start and Adobe Reader (I assume you are invoking Adobe or something similar)
If you are using .NET or Java you simply need to find a PDF viewer component, there are lots to choose from, google will give you plenty of links, Gnostice has a good one, but its expensive. Once you find a suitable control, view the PDF directly from your app.
If there is, process.Start won't be the way, but I'd risk guessing that there isn't.
Unless there's a specific PDF API that allows that somehow (I doubt) I'd save it to disk.
Related
I'm trying to read data and attributes from an opened PDF file which is on screen.
Is there a way of attaching to running acrobat reader and manipulating data from it ?
Attaching to another process means that you will have to handle a lot of inter-process-communication (IPC). Apart from that, you don't know what Acrobat Reader looks like inside. So you cannot simple ask it to deliver you some bytes.
Instead, you should use one of the many libraries to open, display and read PFD-files like iTextSharp. I am certain that these will serve purposes well.
There are many more libraries available, you should have a look at PDFSharp.
I have never done it my self, but a quick look around I found that the Acrobat Reader (assuming that is what you are talking about) has an API which (by looking at its documentation) has an IPC module which will be the closest to what you are asking for.
I am trying to write a tcp reconstruction program in c# , by using SharpPcap. So far I am doing a pretty good job, and the reconstruction is working fine. My only problem is, that in order to reconstruct big Pcap files by myself, I need to load them by parts/chunks to the memory, because sharppcap only let's me load the whole file( I think). Any suggestions?
Thanks
The pcap file format is really simple, see here: http://wiki.wireshark.org/FileFormatReference/libpcap
Why not load the file yourself, possibly a packet at a time, and then you can do what you want as you go along rather than having a library dictate your memory usage patterns?
Given that SharpPcap PcapDevices have a GetNextPacket method, from which both LibPcapLiveDevice and CaptureFileReaderDevice inherit that method, I don't see anything that would require you to load the whole file - you might have to read the entire file, but you can just ignore packets you don't want.
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
In my web application I am working with files. Some files are very large. I use Response.Write() to write the file to the browser. This goes well for the smaller files, but for large files this can take a while and the bandwidth is fully used.
Is it possible to split large documents and send it piece by piece to the browser? Are there other ways to send the document quicker to the browser?
I hold the document as a property of an object.
Why don't you compress the file and store it in the DB and decompress it will extracting it?
You can do a lot of things depending on this questions:
How often does the file change?
Do I really need the files in the DB?
Why not store the File path in the
DB and the File on disk?
Anyhow, since your files are extremely high bandwidth and you would want your app to respond appropriately you might want to use AJAX load the files Asynchronously. You can have a WebHandler .ashx for this.
Here's a few examples:
http://www.dotnetcurry.com/ShowArticle.aspx?ID=193&AspxAutoDetectCookieSupport=1
http://www.viawindowslive.com/Articles/VirtualEarth/InvokingserversidecodeusingAJAX.aspx
My question is, is it possible to
split large documents and send it
piece by piece to the browser?
It depends on the file type, but in general no. If you are sending something like an excel file or a word doc etc. the receiving application will need all of the information (bytes) to fully form the document. You could physically separate the document into multiple ones, and that would allow you to do so.
If the bandwidth is fully used, then there is nothing you can do to "speed it up" short of compressing the document prior to send. In other words, zip it up.
Depending on the document (I know you said .mht, but we're talking content here) you will see the size go down by some amount. Maybe it's enough, maybe not.
Either way, this is entirely a function of the amount of content you want to send versus the size of the pipe available to send it. One of those is more difficult to change than the other.
Try setting IIS's dynamic compression. By default, it's set fairly low, but you can try setting it for a higher compression level and see how much that helps.
I'm not up to speed with ASP.NET but you might be able to buffer from a FileStream to some sort of output stream.
You can use the Flush method to send the currently buffered data to the client (the browser).
Note that this has some implications, as is described aptly here.
I've considered using it myself, a project sent documents that became fairly large and I was cautious about storing the whole data in memory. In the end I decided the data was not large enough to be a problem though.
Sadly the MSDN documentation is very, very vague on what Flush implies and you will probably have to use Google to troubleshoot.