Check if File is in use

[joethis]

Is there a way to make sure that a file is already in use using asp? For
instance, if one person has opened a file and is about to write to it; then
is there a way to keep another user from reading, or writing to that text
file until the first user is finished?

 

[Bob Barrows [MVP]]

Is there a way to make sure that a file is already in use using asp?
For instance, if one person has opened a file and is about to write
to it; then is there a way to keep another user from reading, or
writing to that text file until the first user is finished?

Use a database. Doing this will severely impair the scalabiltiy of your
application because you will need to serialize this operation. One way to do
it is as follows:

User A renames the file. Opens it and starts updating. User B attempts to
open file, doesn't find it and waits. User A finishes edits saves, closes
and gives file its original name. User B renames it and opens it.

Or do you need to allow multiple users to have it open at the same time? You
might try a "semaphore" system:

User A creates an editlock file and opens the file for editing. Other users
can read the file, but no one else can create another editlock file until
User A is finished. When user A finishes editing the file, he deletes the
editlock file. If other users open a file which is locked for editing, set a
flag in a global variable indicating that the file needs to re-read before
they are allowed to lock it for editing. There are all sorts of gotchas that
can shoot this plan down, so you have to realize that you are attempting to
do the same thing a database management system does, i.e., you are
reinventing the wheel. Use a database.

Bob Barrows

 

[Aaron [SQL Server MVP]]

Is there a way to make sure that a file is already in use using asp? For

instance, if one person has opened a file and is about to write to it; then
is there a way to keep another user from reading, or writing to that text
file until the first user is finished?

Ugh, what if the first user never finished? Leaves his browser open, locks
his workstation, walks outside to get a coffee, and gets run over by a
segway. Or just goes out for lunch, leaving the file locked for an hour or
more. Do you really want web users to wait for this?

 

[joethis]

This is a log that holds errors; so if there is a database problem; then I
would not be able to store that error. That is why I need the file locking
capability. Thanks for the ideas though.

 

[Aaron [SQL Server MVP]]

This is a log that holds errors; so if there is a database problem; then I

would not be able to store that error. That is why I need the file locking
capability. Thanks for the ideas though.

If you are having enough database errors that you need to log them *and*
prevent multiple people from logging errors at the exact same second, I
might suggest a better development cycle that eliminates all of these errors
BEFORE the code is live.

I might also suggest reserving database connection errors for e-mail alerts
or a text log, and everything else for the database.

A

 

[Michael D. Kersey]

This is a log that holds errors; so if there is a database problem; then I
would not be able to store that error. That is why I need the file locking
capability. Thanks for the ideas though.

See the following thread from the archives of this newsgroup:
http://www.google.com/groups?hl=en&...oft.public.inetserver.asp.general&btnG=Search

In that thread, Bill James' post
http://www.google.com/groups?hl=en&lr=lang_en&selm=edNtTewPAHA.129@cppssbbsa04
is most informative.

Notes
=====
1. You can write errors to the IIS log with the Response.AppendToLog()
method.

2. You could lock the Application object for the duration of the update:
Application.Lock
.... do file operations here...
Application.Unlock
....
but this locks out all other pages for the duration.

You could create a separate log filename for each error and write that
file in a subdirectory. The FileSystemObject's GetTempName() method can
create unique filenames for you:
http://aspfaqs.com/ASPScripts/PrintFAQ.asp?FAQID=143

This would eliminate any conflict, since each filename would be unique.
The contents of the error file(s) could be merged in a separate step.

Good Luck,
Michael D. Kersey

 

[Jeff Dillon]

Don't write to the same file. Upon error, generate a unique filename in a
common directory, and write to that. Yes, you'll have multiple error log
files...common practice. Use the date/time and a unique identifier in the
filename.

Jeff