Fixed the "inode is not becoming unbusy" problem.

git-svn-id: file:///srv/svn/repos/haiku/trunk/current@6423 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Axel Dörfler 2004-01-29 23:46:23 +00:00
parent d7a5db30d1
commit b39a7a0edd
2 changed files with 16 additions and 4 deletions

View File

@ -2054,16 +2054,20 @@ Inode::Create(Transaction *transaction, Inode *parent, const char *name, int32 m
index.InsertLastModified(transaction, inode);
}
// Everything worked well until this point, we have a fully
// initialized inode, and we want to keep it
allocator.Keep();
// We hold the volume lock to make sure that bfs_read_vnode()
// won't succeed in the meantime (between the call right
// above and below)!
if ((status = new_vnode(volume->ID(), inode->ID(), inode)) != B_OK) {
// this is a really fatal error, and we can't recover from that
FATAL(("new_vnode() failed with: %s\n", strerror(status)));
DIE(("new_vnode() failed for inode!"));
}
// Everything worked well until this point, we have a fully
// initialized inode, and we want to keep it
allocator.Keep();
if (_id != NULL)
*_id = inode->ID();
if (_inode != NULL)

View File

@ -360,6 +360,10 @@ bfs_sync(void *_ns)
* construction, in which case it waits for that action to be completed,
* and uses the inode object from the construction instead of creating
* a new one.
* ToDo: Must not be called without the volume lock being held. Actually,
* this might even happen with the BDirectory(node_ref *) constructor
* (at least I think so, I haven't tested it yet), so we should better
* test this. Fortunately, we can easily solve the issue with our kernel.
*/
static int
@ -529,6 +533,10 @@ bfs_walk(void *_ns, void *_directory, const char *file, char **_resolvedPath, vn
return status;
}
RecursiveLocker locker(volume->Lock());
// we have to hold the volume lock in order to not
// interfere with new_vnode() here
Inode *inode;
if ((status = get_vnode(volume->ID(), *_vnodeID, (void **)&inode)) != B_OK) {
REPORT_ERROR(status);