I'm using dokan as a file system and don't know how to identify office file write operation. Specially the lock and temp files.
I have to identify them because only the main file has to upload to an external database.
Theoretically I get office word to work but this is more a workaround. I hope there is a special attribute to identify there temp files.
Regard Chris
You can check the ProccessId to see if its Office's proccess. Check if the filename matches temp file. Some Office versions call CreateFile with FILE_FLAG_TEMPORARY and som set it later in SetAttributes. The best way is delay file upload till Cleanup and even then you can add an timer to uplosd it couple of seconds later. (Not sure but I think I remember that OpenOffice closes temp file and then opens it again to call MoveFile).
Hope it helps.
Related
In our WPF application, we must create a Word document and open it automatically.
Today we ask the user to specify the file name and location BEFORE we create the document and them open the file using the Process.Start method.
Now, I want to create the Word document in memory stream, open it and eventually, when the user decides to save the document in Microsoft Word, he will have to specify the location and name. So I will not be using the SaveFileDialog in my app.
This is similar to when you start Microsoft Word. A default document is created and when you click save, you will guided to the "save as" function.
How can I do that?
I don't think you can do this purely on the memory stream. However, I would save the memory stream to a temporary file, by saving to the Temp folder or AppData\temp or something like that with a randomly-generated name, and then mark that file as read-only. Then open word on that file (with System.Diagnostics.Process or however you are doing it), and since it is read-only, it will ask the user to save changes when they exit.
Just programmatically create a new Word document using the standard Microsoft.Interop.Word .Net namespace:
How to: Programmatically Create New Documents
Note that you might need to install MS-Office to do this.
Note, too, that your application can display it's own "Save As" dialog (or, for that matter, could just use a hard-coded path) independent of Word. Your program chooses the path - and your program writes the Word document object if/when it's ready.
Finally, here's an alternative, open source library, DocX:
http://www.codeproject.com/Articles/660478/Csharp-Create-and-Manipulate-Word-Documents-Progra
How to: Open a word processing document from a stream (Open XML SDK)
ADDENDUM:
Thank you for your clarification:
You're using the OpenXML SDK (as an alternative to .Net Interop or DocX libraries I mentioned above). You've already created an in-memory document object.
Now you want the user to be able to open the document object in Word (presumably to review it), before saving it (to a filename of his/her own choosing).
You can't (easily) do that :)
One option, suggested by sovemp above:
a. OpenXML writes to a temp file (so it can be opened in Word)
b. Make the temp file read-only (to force the user to do an explicit "Save As")
c. Use .Net Process.Start() to invoke MSWord (specifying your temp file in your command line).
Another option might be to use a "Preview Handler":
http://www.codeproject.com/Articles/25465/Using-Vista-Preview-Handlers-in-a-WPF-Application
https://previewhandlers.codeplex.com/
Still another option might be to serve the memory stream in a web browser, using HTTP ContentType "application/msword" (for example)
Finally, if all you want is for the user to specify a filename (if "preview" isn't essential), you can always pop up your own "Save as" dialog and write document to disk directly from OpenXML.
I have written a C# function for
1) Generating PDF file into folder in its own solution.
2) making entry into SQL database with PDF file name & its size.
I want to,
=> Rollback the PDF generation if the Data insertion into the Database fails.
Because the File may not be used in future.
i.e. If someone stops the Process in the middle before the entry made into Database then for that situation I have to use precaution like this.
Because the File may not be used in future.
Is it possible to rollback the Generation of PDF?
The simple solution is to delete the generate Pdf file when the database update fails. Deleting a file is fairly easy File.Delete(fileName);
You can use transactional file manager library given by codeplex along with transactionscope to achieve your task. Here is the link as to how you can implement transactional file manager along with database transaction.
Also the newer versions of windows has something called TxF (Transactional NTFS) which you can use. Check out the link here. Not very sure if this will address your problem but you can definitely try.
Hope this helps.
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.
There is a virus that my brother got in his computer and what that virus did was to rename almost all files in his computer. It changed the file extensions as well. so a file that might have been named picture.jpg was renamed to kjfks.doc for example.
so what I have done in order to solve this problem is:
remove all file extensions from files. (I use a recursive method to search for all files in a directory and as I go through the files I remove the extension)
now the files do not have an extension. the files now look like:
I think this file names are stored in a local database created by the virus and if I purchase the anti virus they will be renamed back to their original name.
since my brother created a backup I selected the files that had a creation date latter than when my brother performed the backup. so I have placed that files in a directory.
I am not interested in getting the right extension as long as I can see the content of the file. for example, I will scan each file and if it has text inside I know it will have a .txt extension. maybe it was a .html or .css extension I will not be able to know that I know.
I belive that all pdf files should have something in common. or doc files should also have something in common. How can I figure what the most common types (pdf, doc, docx, png, jpg, etc) files have in common)
Edit:
I know it will probably take less time to go over all this 200 files and test each one instead of creating this program. it is just that I am curios to see if it will be possible to get the file extension.
In unix, you can use file to determine the type of file. There is also a port for windows and you can obviously write a script (batch, powershell, etc.) or C# program to automate this.
First, congratulate your brother on doing a backup. Many people don't, and are absolutely wiped out by these problems.
You're going to have to do a lot of research, I'm afraid, but you're on the right track.
Open each file with a TextReader or a BinaryReader and examine the headers. Most of them are detectable.
For instance: Every PDF starts with "%PDF-" and then its version number. Just look at those first 5 characters. If it's "%PDF-", then put a PDF on the filename and move on.
Similarly: "ÿØÿà..JFIF" for JPEG's, "[InternetShortcut]" for URL shortcuts, "L...........À......Fƒ" for regular shortcuts (the "." is a zero/null, BTW)
ZIPs / Compressed directories start with {0x50}{0x4B]{0x03}{0x04}{0x14}, and you should be aware that Office 2007/2010 documents are really ZIPs with XML files inside of them.
You'll have to do some digging as you find each type, but you should be able to write something to establish most of the file types.
You'll have to write some recursion to work through directories, but you can eliminate any file with no extension.
BTW - A great tool to help pwith this is HxD: http://www.mh-nexus.de/ It's what I used to pull this answer together!
Good luck!
"most common types" each have it's own format and most of them have some magic bytes at the fixed position near beginning of the file. You can detect most of formats quite easily. Even HTML, XML, .CSS and similar text files can be detected by analyzing their beginning. But it will take some time to write an application that will guess the format. For some types (such as ODF format or JAR format, which are built on top of regular ZIPs) you will be also able to detect this format.
But ... Can it be that there exists such application on the market? I guess you can find something if you search, cause the task is not as tricky as it initially seems to be.
What is the best way to open a Word file that was stored as a byte[] in a database?
I have to store some documents in an Access database - Word files, 2003 and up - on an application that is strictly run off of a CD. Unfortunately they have to be in the database and can't be stored loose in folders. I'm storing them as an OLE object, and I can read and write them just fine as a byte[].
However, I don't know the best way of getting these documents back open in Word. Right now I'm using a FileStream to recreate the file in somewhere and then shooting off a System.Diagnostics.Process.Start(filename) to get it to open. This is going to be used on government computers which can have some funky security rules sometimes, so I don't know if this is the best way.
Is it possible to open a file previously stored as a byte[] without using any intermediary file saved to the hard drive? I know they'll at least have Word 2003, so I'm open to using the Word interop.
Thanks for any input!
I doubt you're going to be able to feed Word a file in memory without saving it to at least a RAMDisk or something wild like that.
Why not use the system temp folder or the GetTempFile() method to write the byte array to a file just before opening it using Word and then cleaning up the temp files when you're done?
string fullPathToATempFile = System.IO.Path.GetTempFileName();
// or
string tempDirPath = System.IO.Path.GetTempPath();