Remove Filesystem mount properly

[sebastian.vesenmayer]

Hello,

I cannot find the function to remove a filesystem mount which takes a FileSystemMountPtr. What is the supposed way to do this?

Why have the .umount file not been deleted after calling Unigine::FileSystem::clearMounts()?

Thanks

[sebastian.vesenmayer]

Another question: Is it possible to mount a folder which location is in the root folder (Like C:\assets\), because I cannot mount anything there.

Edit: Maybe "run as Administrator" is required then?

Edited March 25, 2020 by sebastian.vesenmayer

[silent]

sebastian.vesenmayer

You can unmount directory via API following way:

FileSystem::removeMount(FileSystemMount::getVirtualPath());

.umount file is user-generated content, so you need to remove it manually if you no longer require it.

 

Quote

Is it possible to mount a folder which location is in the root folder (Like C:\assets\), because I cannot mount anything there.

You need to have read/write access for current user at disk C:\ for mounts to work correctly. Windows have some additional security checks here. In theory admin priveleges may help.

Thanks!

[sebastian.vesenmayer]

Thanks will try this :)

[sebastian.vesenmayer]

Hello silent,

 

works so far but we ran into another problem during migration from 2.8 to 2.10.

We are adding some folders into the Filesystem after Unigine engine has been initialized.

When the folders are empty it is fine.

But when we add a folder with content the application never returns from this function call.

"Unigine::FileSystem::createMount(pathtoasset.c_str(), "ourassets", Unigine::FileSystemMount::ACCESS_READONLY);"

Are there any restriction to the content when calling this function (filetypes, filenames, number of files, folder trees)?

What is happening when calling this function (parsing of files, recursions, loops)?

Why is it not possible anymore to load directly from the windows filesystem which worked very well?

 

Thank you

[silent]

Can you create mount point inside the Editor or it will also hang? Looks like a bug to me, because no changes were specifically made to the mounts. There is, however some known issues (data from mount points loaded twice in 2.10 - it's already has been fixed in 2.11-beta release).

If you just started your migration process I guess it would be better to wait until the 2.11 release (ETA: the end of the next week) with this issue being fixed. If you also can check the same behavior with 2.11-beta to see if this behavior still can be reproduced - it would be just great. How do you think - will it work in your case?

 

Quote

Why is it not possible anymore to load directly from the windows filesystem which worked very well?

Do you mean mutiple data_path command line option? Could you please give us more info on this?

[sebastian.vesenmayer]

18 minutes ago, silent said:

Can you create mount point inside the Editor or it will also hang? Looks like a bug to me, because no changes were specifically made to the mounts. There is, however some known issues (data from mount points loaded twice in 2.10 - it's already has been fixed in 2.11-beta release).

I can create a mount point at these location when I create a fresh unigine project from scratch.

I have a stack trace where it halts if it helps.

 	ntdll.dll!00007fff5531c744()	Unbekannt
 	KernelBase.dll!00007fff530c6951()	Unbekannt
>	[Inlineframe] Unigine_double_x64d.dll!Unigine::doBackoff(int &) Zeile 206	C++
 	[Inlineframe] Unigine_double_x64d.dll!Unigine::BackoffSpinner::spin() Zeile 217	C++
 	Unigine_double_x64d.dll!Unigine::RWMutex::lockRead() Zeile 317	C++
 	[Inlineframe] Unigine_double_x64d.dll!Unigine::ScopedReaderLock::{ctor}(Unigine::RWMutex &) Zeile 308	C++
 	Unigine_double_x64d.dll!FileSystem::getVirtualPath(const char * path) Zeile 2920	C++
 	Unigine_double_x64d.dll!FileSystem::getMount(const char * path) Zeile 595	C++
 	Unigine_double_x64d.dll!FileSystem::check_mount_circular_dependencies(const FileSystemMount * mount, const char * absolute_dir_path, Unigine::Vector<FileSystemMount *,int,Unigine::VectorAllocator> & candidates) Zeile 924	C++
 	Unigine_double_x64d.dll!FileSystem::check_mount_circular_dependencies(const FileSystemMount * mount, const char * absolute_dir_path, Unigine::Vector<FileSystemMount *,int,Unigine::VectorAllocator> & candidates) Zeile 908	C++
 	Unigine_double_x64d.dll!FileSystem::validate_mount(FileSystemMount * mount, Unigine::Vector<FileSystemMount *,int,Unigine::VectorAllocator> & candidates) Zeile 1035	C++
 	Unigine_double_x64d.dll!FileSystem::validate_mount(FileSystemMount * mount) Zeile 1049	C++
 	Unigine_double_x64d.dll!FileSystem::createMount(const char * absolute_path, const char * virtual_path, int access) Zeile 655	C++
 	Unigine_double_x64d.dll!Unigine::FileSystem::createMount(const char * absolute_path, const char * virtual_path, int access) Zeile 35	C++

 

 

18 minutes ago, silent said:

If you just started your migration process I guess it would be better to wait until the 2.11 release (ETA: the end of the next week) with this issue being fixed. If you also can check the same behavior with 2.11-beta to see if this behavior still can be reproduced - it would be just great. How do you think - will it work in your case?

We are planning to move to 2.11 soon after we finished migration to 2.10. But we can try this the next days.

 

 

18 minutes ago, silent said:

Do you mean mutiple data_path command line option? Could you please give us more info on this?

It was possible to just set path to textures like:

unigine_material->setTexturePath(textureID, "C:\\textures\\mytexture.dds");

This is not working anymore.

Edited March 26, 2020 by sebastian.vesenmayer

[silent]

Quote

I have a stack trace where it halts if it helps.

That's interesting, thanks for details! However, a minimal test scene will be a better option here. I've tried to mount different folder in different projects with 2.10 and 2.11 and so far no crashes appeared.

 

Quote

But we can try this the next days.

That would be great!

 

Quote

unigine_material->setTexturePath(textureID, "C:\\textures\\mytexture.dds");

Oh, I see. More likely it's because RenderManager internally was rewritten to use the GUID-based logic. I will ping devs to understand if we can return previous behavior back or not. Thank you for pointing that out!

[sebastian.vesenmayer]

1 hour ago, silent said:

That's interesting, thanks for details! However, a minimal test scene will be a better option here. I've tried to mount different folder in different projects with 2.10 and 2.11 and so far no crashes appeared.

This seems like a deadlock in the RWMutex, maybe there are race conditions occuring.

[silent]

Quote

This seems like a deadlock in the RWMutex, maybe there are race conditions occuring.

Yep, we were able to reproduce this deadlock internally. Will be fixed in 2.11 release (beta is still affected, so there is no much sense right now to test this exact case).

[silent]

Regarding setTexturePath and absolute path values - it will not be fixed in 2.11, but we can send you a patch right after the 2.11 release to resolve this issue.

[sebastian.vesenmayer]

6 hours ago, silent said:

Yep, we were able to reproduce this deadlock internally. Will be fixed in 2.11 release (beta is still affected, so there is no much sense right now to test this exact case).

Good to know, we did workarround this with a thread sleep for 4 mounted folders and could finally load the mount points. But startup is now taking much more time than in 2.8. Maybe 2.11 will speed this up again.

 

5 hours ago, silent said:

Regarding setTexturePath and absolute path values - it will not be fixed in 2.11, but we can send you a patch right after the 2.11 release to resolve this issue.

Is it planned in the future to delete the ability to load files from not mounted filesystem locations? If this is the case we are going to use the filesystem mounts beignning from version 2.10.

[silent]

Quote

Is it planned in the future to delete the ability to load files from not mounted filesystem locations? If this is the case we are going to use the filesystem mounts beignning from version 2.10.

We don't have any plans to remove such functionality yet.

 

Quote

But startup is now taking much more time than in 2.8. Maybe 2.11 will speed this up again

In 2.11 it should be faster for sure. Due to bug in 2.10 all the mount files are simply loaded twice.