Shared folders IFS for VBox Additions, the test version

[Valery Sedletski]

2Lars:

> Ok, now I got a little bit further. It now mounts and the command line view on files and folders is ok.

And what was the problem? VBoxService.exe not started?

> But WPS only shows folders (from the mount point) but not the files. Also, funny enough but no changeable because of lack of EAs, the view always reverts to "Tree View", even if I select "Icon View" from the Properties->menu.

RMB->Open as->Icon View does not work? It opens an Icon View fine for me... Strange. Newer saw such situation as you have. EA's are present, empty ones.

> Browsing around in the mounted directory tree traps the WPS but it recovers.

How did you achieved this? Never saw such problem.

> I have the same prob as Mauro: I cannot copy anything from the mounted folder to my OS/2 virtual guest drive.
I have removed the read-only bit from the mounted folder (which is an NTFS volume of my Windows Host) but it does not make a difference at all.

The current folder is readonly. Open File Commander, choose Files->File attributes and remove "read only" checkbox. Remove "read only" flag not in
VBox shared folder settings, but a "read only" DOS attribute flag on the file system, with FC/2 or attrib command.

[Valery Sedletski]

> Browsing around in the mounted directory tree traps the WPS but it recovers.

Maybe, you're using OS/4 kernel and WPS tries to start dmisl.exe and it traps, which cause WPS trap too? can you check this?
OS/4 has DosQueryRASInfo function unimplemented so, dmisl,exe fails. I noticed that when using WPS Drives object and browsing
the directory around, like you described. This time WPS tries to start dmisl,exe and it traps, which freezes the WPS. I observed this
with OS/4 kernel, but maybe such problems exist on IBM kernels too. Can you check this with attaching a terminal emulator to VM
COM port? Or, at least, rename dmisl.exe and see if the problem will go away?

> Also, funny enough but no changeable because of lack of EAs, the view always reverts to "Tree View", even if I select "Icon View" from the Properties->menu.

Maybe, that time you had "read only" checkbox set in VBox shared folder setting, so WP ROOT. SF file was not writable, and hence, you cannot
change root directory properties? Or just WP ROOT. SF file is readonly? Or, maybe, you have some permission problems on your NTFS drive?
Can you check this? This file contains EA's of the root directory of each drive.

[Valery Sedletski]

Sorry, in r217, I repaired FS32_FILEINFO/FS32_PATHINFO with FIL_QUERYEASFROMLIST[L], but broke FIL_QUERYALLEAS.
Now I returned it back to the previous state, so it should work. Here is the fixed version:

ftp://osfree.org/upload/vbox/additions/VBoxAdditions-os2-x86-5.0.51.r218.zip

In r217, it made FC/2 trapped when copying files. Though, WPS copy worked successfully.

[Lars]

No I am not using OS/4 kernel.
As I said, I had removed "read-only" on the shared folder. "WP ROOT. SF" was created.
I made it trap just by browsing in the tree via WPS.
I cannot copy files,even from a command line. I repeat,neither the shared folder nor the target directory is read-only. Yes,I am talking about DOS file/folder attributes.

There clearly was a problem with EAs. I'll try 218.

[Lars]

r218:
1) I can now copy to and from shared folder from an OS/2 commandline.
2) EA support still broken: in WPS, I can only see folders, no files, the WPS crashes when browsing folder tree, I cannot set default view

Yes, I double checked, I have r218 installed.

[Lars]

Valery,

please have a look at FS_FINDFIRST,FS_FINDNEXT,FS_FINDCLOSE,FS_FINDFROMNAME regarding EA support.
There must be something wrong in these routines.
Maybe you even want to look at all information levels: FIL_STANDARD,FIL_STANDARDL,FIL_QUERYEASIZE,FIL_QUERYEASIZEL,FIL_QUERYEASFROMLIST,FIL_QUERYEASFROMLISTL

[Valery Sedletski]

2Lars: Ok, so it was broken FIL_QUERYALLEAS in your case, not what I thought. What is "set default view"? RMB->Open as->Icon view
works fine. View->Icon View too. Do you try something other? Please provide logs 1) when WPS is crashed 2) When setting icon view fails.
Please interrupt the log when the error is occured, i.e., what was the last in the log. Or help me reproduce this on my machine. As I have
no Windows 10 on a bare hardware. I only have OS/2 with VBox 5.0.51 and Linux with VBox 6.1.2, plus Windows XP with VBox 5.2 which
don't have problems like you describe.

[Lars]

Yes, "set default" view means RMB->Menu->Open as->Icon view

Valery, I have close to no time for this. I cannot support you any more than saying that EA support has a bug.
If you tell me where to look at the source for VBOXFS.IFS , I might find time to have a look at it but I cannot guarantee.

Lars

[Valery Sedletski]

2Lars: I was editing my last answer in this thread, so please reread it. Please provide logs. The source is here:

http://trac.netlabs.org/vbox/browser/trunk/src/VBox/Additions/os2/VBoxFS

As you can see, everything made the same way it's done in fat32.ifs (I used it as a template). The difference is
that code is 32-bit. EA's work fine, there is some windows-specific problem. The logs are enabled with "/d"
parameter in IFS command line. You can use latest version of Putty to redirect VM COM port to a terminal
emulator via a named pipe. You can google a tutorial how to redirect a VM COM port via a host named pipe/socket
to a terminal emulator, like Putty, minicom or DTerm on different platforms. E.g. this one:

https://www.reactos.org/wiki/VirtualBox?uselang=ru

Also, I have some info described in debug.txt provided with the aditions ISO.

PS: Look here if you don't believe me: https://imgur.com/a/n4NsdbI. I can open Icon or Detailed or Tree view
without any problems. I repeat that this is some windows-specific problem. But I cannot determine what's going
on in your system without any logs.

[Lars]

I did a PuTTY dump, I am attaching a short sequence of it:

VBOXFS: P:25 T:9E D:0 t=28.958 FS32_PROCESSNAME(E:\*)
VBOXFS: P:25 T:9E D:0 t=28.966 FS32_FINDFIRST(E:\*, 1077, 3, 1)
VBOXFS: P:25 T:9E D:0 t=28.990 pFile=*
VBOXFS: P:25 T:9E D:0 t=28.992 pFile2=*
VBOXFS: P:25 T:9E D:0 t=28.994 str=
VBOXFS: P:25 T:9E D:0 t=28.996 wildcard: *
VBOXFS: P:25 T:9E D:0 t=28.998 g_pGIS=ffdbc280
VBOXFS: P:25 T:9E D:0 t=29.0 timezone=0 minutes
VBOXFS: P:25 T:9E D:0 t=29.1 GetEmptyEAs: rc=0
VBOXFS: P:25 T:9E D:0 t=29.3  => 0
VBOXFS: P:25 T:9E D:0 t=29.5 FS32_FINDFFROMNAME(.)
VBOXFS: P:25 T:9E D:0 t=29.5 FS32_FINDNEXT(3, 1)
VBOXFS: P:25 T:9E D:0 t=29.7 g_pGIS=ffdbc280
VBOXFS: P:25 T:9E D:0 t=29.9 timezone=0 minutes
VBOXFS: P:25 T:9E D:0 t=29.11 GetEmptyEAs: rc=0
VBOXFS: P:25 T:9E D:0 t=29.23 GetEmptyEAs: rc=0
VBOXFS: P:25 T:9E D:0 t=29.35  => 0
VBOXFS: P:25 T:9E D:0 t=29.37  => 0
VBOXFS: P:25 T:9E D:0 t=29.37 FS32_FINDFFROMNAME(install)
VBOXFS: P:25 T:9E D:0 t=29.39 FS32_FINDNEXT(3, 1)
VBOXFS: P:25 T:9E D:0 t=29.39 g_pGIS=ffdbc280
VBOXFS: P:25 T:9E D:0 t=29.41 timezone=0 minutes
VBOXFS: P:25 T:9E D:0 t=29.42  => 18
VBOXFS: P:25 T:9E D:0 t=29.42  => 18
VBOXFS: P:25 T:9E D:0 t=29.44 FS32_FINDCLOSE
VBOXFS: P:25 T:9E D:0 t=29.46 FS32_PROCESSNAME(E:\)
VBOXFS: P:25 T:45 D:0 t=6.195 FS32_ATTACH(2, E:)
VBOXFS: P:25 T:45 D:0 t=6.197  => 0
VBOXFS: P:25 T:45 D:0 t=6.197 FS32_PROCESSNAME(E:\A.+,;=[].B)
VBOXFS: P:25 T:45 D:0 t=6.199 FS32_OPENCREATE(E:\A.+,;=[].B, c0, 1, 60)
VBOXFS: P:25 T:45 D:0 t=6.201 pszFullName=A.+,;=[].B
VBOXFS: P:25 T:45 D:0 t=6.203 fail
VBOXFS: P:25 T:45 D:0 t=6.203 rc=0
VBOXFS: P:25 T:45 D:0 t=6.205  => 110
VBOXFS: P:25 T:45 D:0 t=6.337 FS32_FSINFO(1fe, 0, 1)
VBOXFS: P:25 T:45 D:0 t=6.341  => 0
VBOXFS: P:25 T:45 D:0 t=6.402 FS32_PROCESSNAME(E:\)
VBOXFS: P:25 T:45 D:0 t=6.402 FS32_PATHINFO(0, E:\, 1)
VBOXFS: P:25 T:45 D:0 t=6.406  => 0
VBOXFS: P:25 T:45 D:0 t=6.408 FS32_ATTACH(2, E:)
VBOXFS: P:25 T:45 D:0 t=6.408  => 0
VBOXFS: P:25 T:45 D:0 t=6.410 FS32_PROCESSNAME(E:\A.+,;=[].B)
VBOXFS: P:25 T:45 D:0 t=6.412 FS32_OPENCREATE(E:\A.+,;=[].B, c0, 1, 60)
VBOXFS: P:25 T:45 D:0 t=6.412 pszFullName=A.+,;=[].B

E:\ is the shared drive (NTFS) on my Win10 host, under Win10 it contains the "." and ".." directories, a couple of files and also a subdirectory "install".
What is really odd is that apparently VBOXFS.IFS is passed "A.+,;=[].B" as a filename to look for. But that rather looks like the characters that are forbidden to use in a filename (more or less). How are you handling this call ? Does this also happen with Linux as a host (instead of Windows) ?
And then the "." and ".." directories: how do you handle these ? Do these two directories also show up under Linux ?

Also, after on the find on the "install" directory, VBOXFS.IFS apparently returns with a SYS0018 which means: "no more files found" and which is certainly wrong.

Tell me where to move this discussion. To the VBOX bug tracker at netlabs ?

Lars

[Lars]

Just a last question: are you sure that the FEA and GEA and other EA related structures are byte-packed ?
Have you used #pragma pack(1) to ensure that ?
I am asking as a 32-bit compiler will normally assume 4-byte aligned packing if not told otherwise.

[Valery Sedletski]

2Lars: of course all structures are byte-packed. You can ensure that this is done in EMX/kLIBC headers.

What action is this log you gave for? WPS crashed or setting icon view fail, or whatever?
Of course, I display . and .. dir entries. FS32_FINDFIRST/NEXT are well-debugged for a long time, so they
display everything correctly. "A.+,;=[].B" is not that VBoxFS displays, but what WPS fills the find buffer with.
It is given to any IFS. So, this is not my problem, but a WPS problem. And this, of course, does not depend
on the host. The same request is given to fat32.ifs too.

> Also, after on the find on the "install" directory, VBOXFS.IFS apparently returns with a SYS0018 which
means: "no more files found" and which is certainly wrong.

This is not wrong, this means that the file list is just ended. It's normal.
As I said, this code is well-debugged. it displays everything correctly. You can look with FC/2,
if WPS is not working for you. The problem with WPS is with something other.

> Tell me where to move this discussion. To the VBOX bug tracker at netlabs ?

The bug tracker is ok, of course. But here is also ok. I don't see why we cannot continue
the conversation here.

Anyway, I decided to install Win7 x86_64 on my laptop and see all the problems myself.

[mauro]

my feedback is:  in the Windows hosted machine files copying is now working from/to shared folder in WPS with r218 ! Have not tried on Ubuntu hosting yet, will let you know

Meantime I confirm that files copying was allowed by command line session with my r216 installation (didn't tried this before).
Very good.

[Valery Sedletski]

2mauro: Shared folders in console programs worked for the long time, indeed. It's I broke it a bit in version r217. In r216, or older, on r218 everything
is working fine. I even ran a 8-hour build of complete VBox sources over a shared folder, and nothing got broken. What is not complete working atm
are dummy EA's which are required by WPS. So, currently (at least, on VBox 6.x in Linux and on VBox 5.0 on OS/2 host) I am able to open a WPS
Drives object, browse directories and copy files. Sometimes WPS gets stuck, or copying files fails, because current directory of that file becomes
read only. But if I remove the "readonly" bit, copying works. Also what I noticed is that if I open a file properties in WPS, I see only one "Icon" tab
in the settings notebook. No "Become", "File", or other tabs. On the HPFS/JFS/FAT32/emsFS disks these tabs are present. No idea yet, what's wrong
with EA's. Obviously, this is caused by incorrect EA's.

[mauro]

I confirm that r218 is good working same on my Ubuntu hosting as well.

Should the "readonly bit" issue happens, how do I exactly set it back on the correct status?
Thank you