"JET_errFileAccessDenied, Cannot access file, the file is locked or in use" on shared host

[friism]

Im trying to get RavenDB running in embedded mode out of the App_Data
folder in a shared hosting setting (Full Trust) working. I'm getting
"Error FileAccessDenied (JET_errFileAccessDenied, Cannot access file,
the file is locked or in use)". There's some related discussion here:
https://groups.google.com/forum/#!topic/ravendb/6A_i1HoDSgo

I'm fairly confident that this is not at permissions issue. For
example, if I run this code, the file write succeeds, but the RavenDB
write fails:

public ActionResult Index()
{
using (var writer = new StreamWriter(Server.MapPath("~/App_Data/
foo.txt")))
{
writer.Write("baz");
}

var documentStore = new EmbeddableDocumentStore();
documentStore.DataDirectory = Server.MapPath("~/App_Data");
documentStore.Initialize();

using (var session = documentStore.OpenSession())
{
var document = new
{
Foo = "bar",
};
session.Store(document);
session.SaveChanges();
}

return View();
}

I've reviewed and tested the TransactionalStorage#ctor
(Raven.Storage.Esent.TransactionalStorage), lines 70-83, and that
seems to be doing its job correctly, setting up the path.

Any suggestions?
Michael

[Matt Warren]

Is there any chance that 2 threads are trying to set up the RavenDB
store at the same time?

[friism]

On Jul 14, 3:48 pm, Matt Warren <mattd...@gmail.com> wrote:
> Is there any chance that 2 threads are trying to set up the RavenDB
> store at the same time?

I've just tried to Initialize() in Application_Start() and putting the
DocumentStore in ApplicationState. That should ensure that only one is
ever created. I still get the same exception. Controller now looks
like this:

public ActionResult Index()
{
using (var writer = new StreamWriter(Server.MapPath("~/App_Data/
foo.txt")))
{
writer.Write("baz");
}

using (var session = (HttpContext.ApplicationInstance as
MvcApplication).
DocumentStore().OpenSession())

{
var document = new
{
Foo = "bar",
};
session.Store(document);
session.SaveChanges();
}

return View();
}

DocumentStore() does "return this.Application["documentStore"] as
EmbeddableDocumentStore;"

[Frank Schwieterman]

Was the Data directory actually created? Maybe it has sufficient
permissions to create a directory, but the permissions aren't set to
be inherited, causing a failure when trying to write to the Data
directory. Maybe verify you can create a directory and write a file
to it. (I'm just guessing here, haven't seen this problem)

[friism]

On Jul 14, 4:36 pm, Frank Schwieterman <fschw...@gmail.com> wrote:
>   Was the Data directory actually created?  Maybe it has sufficient
> permissions to create a directory, but the permissions aren't set to
> be inherited, causing a failure when trying to write to the Data
> directory.  Maybe verify you can create a directory and write a file
> to it.  (I'm just guessing here, haven't seen this problem)

Your suggestions and guesses are greatly appreciated. Directory
permission inheritance does not seem to the issue either though. This
code still fails at the RavenDB write:


public ActionResult Index()
{
Directory.CreateDirectory(Server.MapPath("~/App_Data/Data2"));

using (var writer = new StreamWriter(Server.MapPath("~/App_Data/

Data2/foo.txt")))

[friism]

On Jul 14, 4:36 pm, Frank Schwieterman <fschw...@gmail.com> wrote:

>   Was the Data directory actually created?  Maybe it has sufficient
> permissions to create a directory, but the permissions aren't set to
> be inherited, causing a failure when trying to write to the Data
> directory.  Maybe verify you can create a directory and write a file
> to it.  (I'm just guessing here, haven't seen this problem)

Your suggestions and guesses are appreciated. The problem does not
seem to be with permission inheritance though, this still nets the
same exception:

public ActionResult Index()
{
Directory.CreateDirectory(Server.MapPath("~/App_Data/Data2"));

using (var writer = new StreamWriter(Server.MapPath("~/App_Data/

Data2/foo.txt")))

[Ayende Rahien]

Things to check, that the IIS users have full write permissions there.

That there isn't any anti virus running that may decide to mess things up.

That there isn't double initialization going in here.

You might want to look at file watcher and see what is actually going on.

[friism]

On Jul 15, 1:32 am, Ayende Rahien <aye...@ayende.com> wrote:
> Things to check, that the IIS users have full write permissions there.
> That there isn't any anti virus running that may decide to mess things up.
> That there isn't double initialization going in here.
> You might want to look at file watcher and see what is actually going on.

This turns out to be some subtle ESENT permission issue. I've posted a
question on ServerFault: http://serverfault.com/questions/292545/esent-fails-to-determine-the-minimum-i-o-block-size

Michael