Uploading already use file
-
Hi, In my windows application i am using file dialog box for uploading the file. If the file is in use i am not able to upload its giving exception. How can i solve it,i mean to say if still the file is in use i want to upload it. Can any one suggest me how can i do it ? Thanks in advance.
-
Hi, In my windows application i am using file dialog box for uploading the file. If the file is in use i am not able to upload its giving exception. How can i solve it,i mean to say if still the file is in use i want to upload it. Can any one suggest me how can i do it ? Thanks in advance.
If another application has the file open, and locked for reading, you cannot read from it. That's an OS level restriction. You can give yourself a chance by requesting a read-sharable lock to the file yourself:
FileStream fs = File.Open(filename, FileMode.Open, FileAccess.Read, FileShare.Read);
This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open. Check that your own application isn't opening a file and forgetting to close it, though. That's a good way of creating this exception that can be fixed. You can generally put a FileStream or StreamReader in a using block which makes sure it is always closed.
-
If another application has the file open, and locked for reading, you cannot read from it. That's an OS level restriction. You can give yourself a chance by requesting a read-sharable lock to the file yourself:
FileStream fs = File.Open(filename, FileMode.Open, FileAccess.Read, FileShare.Read);
This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open. Check that your own application isn't opening a file and forgetting to close it, though. That's a good way of creating this exception that can be fixed. You can generally put a FileStream or StreamReader in a using block which makes sure it is always closed.
-
If another application has the file open, and locked for reading, you cannot read from it. That's an OS level restriction. You can give yourself a chance by requesting a read-sharable lock to the file yourself:
FileStream fs = File.Open(filename, FileMode.Open, FileAccess.Read, FileShare.Read);
This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open. Check that your own application isn't opening a file and forgetting to close it, though. That's a good way of creating this exception that can be fixed. You can generally put a FileStream or StreamReader in a using block which makes sure it is always closed.
BobJanova wrote:
This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open.
I don't agree on you that it is bad practice. If MS Word is doing intermittent writes to it and share it for reading, then another application reading the file could get strange results, where the first half of the file is 'old' and the second half is 'new'. Locking files (appropriately) while in use is a good thing. Consider a user deleting a file, and it keeps coming back. "Why is this happening?!". Because the application that is writing to the file doesn't have it locked, so at every write it comes back*. With locks, the user gets the immediate error that the file is in use. The lock is there because the file is in use, and access to it can't reasonably work properly, so it is protecting other applications. * slightly fictional situation, but it is a good example of why files have locks
-
BobJanova wrote:
This will succeed where an attempt to open the file read/write won't if another application has done the same thing. However, most applications lock files completely while in use (and some, notably MS Office, keep the file locked while it is open ... bad practice, that), and there is simply no way to read such a file while the other application has it open.
I don't agree on you that it is bad practice. If MS Word is doing intermittent writes to it and share it for reading, then another application reading the file could get strange results, where the first half of the file is 'old' and the second half is 'new'. Locking files (appropriately) while in use is a good thing. Consider a user deleting a file, and it keeps coming back. "Why is this happening?!". Because the application that is writing to the file doesn't have it locked, so at every write it comes back*. With locks, the user gets the immediate error that the file is in use. The lock is there because the file is in use, and access to it can't reasonably work properly, so it is protecting other applications. * slightly fictional situation, but it is a good example of why files have locks
The file should be locked against reading when it is actually being written. In a document editing app, that should be the time between pressing 'Save' and the save completing. There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it. The basic point I'm trying to make is that yes, locks are for when the file is in use. Once a document is loaded, it is in memory and the file shouldn't be in use; you should be able to open, delete, edit it etc in another editor (as you can with text editors, image editors etc) while it is being viewed in one editor. This is kind of a tangent but I don't mind because I think the OP already got a good answer.
-
The file should be locked against reading when it is actually being written. In a document editing app, that should be the time between pressing 'Save' and the save completing. There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it. The basic point I'm trying to make is that yes, locks are for when the file is in use. Once a document is loaded, it is in memory and the file shouldn't be in use; you should be able to open, delete, edit it etc in another editor (as you can with text editors, image editors etc) while it is being viewed in one editor. This is kind of a tangent but I don't mind because I think the OP already got a good answer.
BobJanova wrote:
There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it
Writing to a text-file is not an atomic operation. Having people read incomplete information might result in bugs that are hard to track.
Bastard Programmer from Hell :suss:
-
BobJanova wrote:
There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it
Writing to a text-file is not an atomic operation. Having people read incomplete information might result in bugs that are hard to track.
Bastard Programmer from Hell :suss:
-
I don't think I can have explained this well. It is absolutely correct that, while the file is being saved, it is locked. What these programs do is lock the file the whole time you are looking at it (i.e. not just when it's updating the file).
Yes. Word locks the file, and keeps a temporary copy - the file is being edited, and cannot be saved in between. It might take 30 minutes to update the file. Time for me to get some sleep, I guess I'm missing the point here :)
Bastard Programmer from Hell :suss:
-
The file should be locked against reading when it is actually being written. In a document editing app, that should be the time between pressing 'Save' and the save completing. There's no reason for a program like Word (or Adobe Reader, lest ye think I'm just being anti-Microsoft) to hold the file open the entire time you are looking at it. The basic point I'm trying to make is that yes, locks are for when the file is in use. Once a document is loaded, it is in memory and the file shouldn't be in use; you should be able to open, delete, edit it etc in another editor (as you can with text editors, image editors etc) while it is being viewed in one editor. This is kind of a tangent but I don't mind because I think the OP already got a good answer.
BobJanova wrote:
The file should be locked against reading when it is actually being written. In a document editing app, that should be the time between pressing 'Save' and the save completing.
You make a very valid point there. However, the implementation holds some problems and I guess that's why it is the way it is now. I'm thinking that if Word would do that, and another program decides to start reading from the file (thus locking it temporarily for writes), any save or write from Word would have to wait until the other program releases its lock. Now, if it is a well behaved program, this might only take a few seconds, but then still, it adds a few seconds to any file write, which can be annoying. This problem you could work around by the OS caching the writes (or the reads) of the other program. Now, suppose the other program is not so well behaved and keeps the read lock for minutes. Then we have Word hanging, or if it's cached the responsibility of the OS to keep all changes to the file cached for a very long time. Well, I guess that it could work if the OS supported it. But only then. As it is now, any program that would try to be 'friendly' and release the lock between writes would become very vulnerable to IO-blocking by other programs. It could be done maliciously, for instance, to indefinitely halt execution of an application. It is indeed a tangent, but I find it interesting to think about the possibilities :)