Assertion failed fs.cpp(144) bool rtFsModeIsValid(RTFMODE) => Fixed in 1.6.4

[ugemkow]

When using a Linux Fedora 7 host and a windows XP guest with shared folders, newest guest additions added, the following assertion failure happens:

!!Assertion Failed!!
Expression: RTFS_TYPE_MASK & fMode
Location :

/lnc/build/apps/make/VirtualBox-1.5.4_OSE/src/VBox/Runtime/fs.cpp(144) bool rtFsModeIsValid(RTFMODE)

00800000

We are using the OSE build 1.5.4 in debug mode. The scenario when this happended was: Using MS Office 2003, SP3, Word with a very large file created by concatenating other files and saving this file. The failure happened during the save operation.

[ugemkow]

log file

[Alex]

Could you try to ignore this assertion and continue the VM execution?

[ugemkow]

Replying to Lelik:

Could you try to ignore this assertion and continue the VM execution?

When doing this (removing the line in the source text) and doing the following steps

• opening an existing (large) file with winword 2003 which has the protection 644

• changing this file (adding large amounts of text)

• trying to save the changed file immeadety

the file save operation takes some time and then an error box in windows says "Word cannot complete the save due to a file permission problem" and the save operation is aborted.

In fact, the created file (same name as the originally opened file) has the protection flags 0000. One of the created tmp-files also has this protection settings.

This was done with a debug-build of VBox OSE 1.5.4.

[Alex]

Tried OSE debug build, assertion is reproducible but I don't see any permissions problem. File mode was 0644 and owner same user as started vbox. File changed and then saved successfully. If the file owner is different, file couldn't be saved of course.

Suppressed assertions with 'export VBOX_ASSERT=none'

[ugemkow]

Thanks for testing, unfortunately I cannot say more. For me this is always reproducible even when only making small changes to the file.

There is a small chance that this is a linux bug, we are using an encrypted filesystem (encrypted with dm-crypto) which probably is not used very often.

I need the debug build only to narrow down crashes we see regulary but I am more than willing to test more if you give me some hint.

[Alex]

Could you try to map shared folder to the another (not encrypted) file system? Just to be sure is it a FS problem or not.

[ugemkow]

Replying to Lelik:

Could you try to map shared folder to the another (not encrypted) file system? Just to be sure is it a FS problem or not.

Yes, this is also reproducible on "normal" file systems and also with other applications (PowerPoint 2003). We have now seen this on different systems (notebooks of different kind).