Hi Andreas,sorry, I accidentally hit "Send" (I managed to not notice that I was already in the editor, and in the mail view, the "Reply" button has the same spot)...
@@ -143,8 +143,17 @@ ResizeVisitor::VisitInode(Inode* inode, const char* treeName) return status; } + // temporary ugliness + char realNameBuffer[B_FILE_NAME_LENGTH]; + const char* realName = realNameBuffer; + if (inode->GetName(realNameBuffer) < B_OK) + realName = NULL;
Why is this only a temporary ugliness? How do you plan to get around it?Also, since Inode::GetName() is supposed to return a status_t, it's preferred to check against != B_OK to not hide a possibly incorrect implementation of GetName() (since I wasn't so wise when I wrote BFS, you probably find a few examples of the < B_OK case, though).
+ // the index root is not managed by the vnode layer, so we set + // 'inode' to point to the correct object
I don't really remember if there is any reason for this, besides speeding up finding indices by keeping a pointer to it around that should not prevent unmounting the volume.
Was there any problem letting this go through the vnode layer?
@@ -121,8 +121,6 @@ ResizeVisitor::VisitInode(Inode* inode, const char* treeName) } else strcpy(name, treeName); - WriteLocker writeLocker(inode->Lock()); - status_t status; off_t inodeBlock = inode->BlockNumber();
Since neither the FileSystemVisitor nor the ResizeVisitor do any locking: how do you prevent that Inode::BlockNumber() changes due to a simultaneous resize or defragmentation or some similar action?
Are new files currently allowed to be created and write to the file system (maybe even beyond the end of the new partition size in case of a shrink)?
Have you something planned for this? Bye, Axel.