Instead of me writing from scratch a text file sharing windows form application, I thought I would simply ask if someone has a snippet (C#) or methodology that I could use?
The application merely needs to create a text file and allow multiple users using the same application from different pcs on the network to append comments to the file. Basically, I am trying to get multiple users to give frequent updates/comments/status changes to a project with this simple app.
I have looked into some filestream locking suggestions, but again, would like to see if anyone would be willing to share a code snippet.
Thanks in advance for any assistance.
Dell
Try using System.IO.File.AppendText method this does everything you are looking for file operation
Remarks taken from MSDN
StreamWriter(String, Boolean) constructor overload. If the file
specified by path does not exist, it is created. If the file does
exist, write operations to the StreamWriter append text to the file.
Additional threads are permitted to read the file while it is open.
The path parameter is permitted to specify relative or absolute path
information. Relative path information is interpreted as relative to
the current working directory. To obtain the current working
directory, see GetCurrentDirectory.
The path parameter is not case-sensitive.This method is equivalent to the
Use Client-Server approach, for example make a WCF service with 2 methods AppendText and GetText, and then only WCF service would write to file.
Here is the example of basic WCF client-server
http://www.switchonthecode.com/tutorials/wcf-tutorial-basic-interprocess-communication
Related
I am looking for idea or hint how fill method/class that need file path in parameter.
f.g
InserFileIntoLibrary(string filePath);
where file path is not C:/ and any other buffored temp directory. Is it possible to make some symulation of file directiory and insert it's file.path value into that string? Problem to solve is that i am sending file between servers, and on other server i have method that can only use memory from program and NO DIRECTORY to buffor/temp this file/stream. Someone has this kind of problem? Or know where to look?
p.s sorry for my english, any kind of corrects are welcom.
Basically no - if you can't save file to disk than you can't get path to such file.
In theory you may be able to create (or use existing) virtual file system, but depending on your budget it may not be acceptable solution. One built-in version is to use WebDAV to access server as \\host\file...
I'd recommend first try to save streams locally - temp folder is normally writable and getting permissions to do so may be way easier.
Also make sure there is no API that performs same task but accepts streams.
I have a web form which takes in user information. The value of various text boxes is used to build a html file. I write this html to a file( with specific name) and then prompt user to Save this file.This html is used for creating outlook email signatures. Currently I have this html within the application.This has been deployed to the server. I had to set write permission on this file for all users for it to work.
Are there any security risks? What happens if multiple users access this applications and write to the file at the same time.
When you say the file has "a specific name", do you mean that it is always the same name? If so, then yes, there will be problems if multiple users use this functionality at the same time. They'll be overwriting the one file and downloading each other's data. You would need to generate a unique filename each time the process runs to avoid this.
But do you actually need to save the file?
Or is your goal purely to produce some HTML for the user to download, and the way you are doing this is by writing it to a file, and then prompting them to download that file?
If you don't need to save the file, but rather just need to generate HTML and prompt the user to save, just serve it up as a normal page, and set response headers such that their browser will download it. Something along these lines:
Response.AddHeader("content-disposition", "attachment;filename=my_file.html");
From what I understand, the user fills the web form and submits. Immediately, an html file pops up for download from the server. I think this is very neat implementation of this scenario. You just need to make sure that resources are released properly in order to prevent locking of files.
When multiple users access this application, it should not break since separate files are created with a specific name (as you have mentioned). I don't know what logic has been used to create unique names. At some peculiar situation (this is purely dependent on your name calculation logic) if the calculated specific file name somehow becomes similar to an existing file, you should have code in place to replace or create a different version of the same file name. Locking could occur if you are writing captured data from web form into the same file again and again without disposing your stream/File objects . Make sure you dispose your objects after use in the code.
It would be great if you give access to the application pool of the web application to a user who has write access to that file/folder instead of giving everyone the write access. In this way, your application gets full rights to perform write operations rather than users having rights. If users have write access on the file/folder, it is very easy for anyone to peek in and do something unexpected.
Hope this helps.
I am working on an application that keeps track and uses files stored on the file system. Users are allowed to open, create, delete and move files in the file system. Meanwhile my application is not constantly running so I can't keep track of all changes real-time. Afterwards my application has to find out what file is whom (i.c. as identified in my application).
The most preferred solution for the users is that the application solves every change itself. Each user-interaction is less preferred.
One of my ideas was to use an attribute of a file and assign a key-value to it so when it has been identified once, it can always been recognized afterwards. But I don't know if there is such an attribute. This article didn't give much hope: There is in Windows file systems a pre computed hash for each file?.
Does somebody know if there is such an attribute I can use? And how can I used it in C#?
Is there anyone who is running up against this problem? And how did you solve it?
I'd like to hear good suggestions.
regards, Jaap
If your files don't leave NTFS, this is easily achievable by alternative data streams, where you can store your data along with files. This is more-or-less good article about ADS: http://www.flexhex.com/docs/articles/alternate-streams.phtml
There is another suitable method - it's very efficient, but also very complicated to use, it requires quite good knowledge about NTFS internals - USN Change Journal; see http://msdn.microsoft.com/en-us/library/windows/desktop/aa363798.aspx. With USN Change Journal, you can "get" very efficiently all files that were changed (even all change events) within specified time period.
Nevertheless, if your files leave NTFS realm, e.g. if it's copied to FAT32, contents of ADS is lost.
Relying on a File attribute is "dangerous" in that some user could alter the attribute while your program isn't running. This could lead you to believe that a certain file is (or isn't) tracked by the program while it really isn't.
I would suggest to keep track of the files in a database, XML, or some other file. When your application starts you read the file/db and check for new/deleted/editted files.
You could store a Hash of the files to find out if a file has been moved/editted. Keeping track of files that are moved AND editted is going to be pretty difficult. (I have no clue how you could achieve it)
PS: Have you considered making your application a Windows service? Having the file-management running in the background no matter if the GUI part of your application is running or not?
There are several related questions on stackoverflow but either my situation is different or I am too dumb to relate those to situation. I am hoping someone can help me with this. Further I am not even much of a .NET developer so I apologize in advance for any wrong terminology use.
My scenario is as follows: The tool that is used to deploy our .net application (One Click?) puts it in a directory whose full name exceeds 300 characters. The application uses a third party component -- lets call it dbstore -- that processes the specified file that resides in the application deployment directory.
So far we were using Assembly.GetExecutingAssembly().GetName().CodeBase to construct the fully qualified name of the file to pass to dbstore. But dbstore uses old style APIs and fails when it tries to open the file.
Since dbstore is not expected to change soon, it was recommended that the application chdir to the deployment directory and pass a relative path name in current directory to it. This is also the approach described in the accepted response PathTooLongException in C# code
However I find that Directory.SetCurrentDirectory also throws PathTooLongException. This happens even when I am using UNC path name, e.g a name starting with \\?\0000000000000\...
Am I doing something fundamentally wrong? Is there another function to use?
EDIT: It seems there is no way to achieve what I am looking for. Far as I can tell there is no way to set current directory to a long path.
Do you get a similar result when using Environment.SetCurrentDirectory() ?
If so, you may want to change your directory subfolder after subfolder.
EDIT:
Windows actually sets a limitation of 255 chars for a file path (WinXP) or 260 chars (Vista).
Note that this limitation does not apply for the filesystem, so you can have a file stored in such a long directory path, but Windows Explorer and many Windows services cannot read from such path.
Actually it seems to also include .NET framework methods since you cannot access such files. You may need to write your own filesystem API, but that's a bit too much overhead. Can't you just shorten the file path ? Does Windows offer a shortened way to address a file (like 8 octet file names) ?
Source: http://labnol.blogspot.com/2006/10/limitations-with-long-file-names-on.html
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.