Weird behavior where wrong files get requested

[W6AKP]

Hello. I'm just getting started, so I'm still learning.

Anyways, I'm trying to make a read-only mounter for VMS ODS2 disks. I have code to read the disk image and all that. Now I'm gluing the two together... I can browse the disk, and stuff seems to work, well enough. Directory listings returned via FindFiles seem good. File dates / sizes look good.

However.. When I open a file in Notepad, it fails saying it cannot find the file. If I use notepad++, it opens the file just fine. If I try to browse from the command prompt, I get "The system cannot find message text for message number 0x13d in the message file for System."

If I try to dir the file, I get the same.
F:>dir "T:\VMS$COMMON\SYSMGR\SYLOGIN.COM;1"
The system cannot find message text for message number 0x13d in the message file for System.

If I try to view the windows properties on the file, I get a huge size, which is related to another file, say "T:\VMS$COMMON\SYSMGR\ACCOUNTNG.DAT;1" (The first file in the directory).

However, if I type it... F:>type "T:\VMS$COMMON\SYSMGR\SYLOGIN.COM;1" All kinds of weird stuff goes on!

I've put tracing in my app, and what happens is a CreateFile is called for "T:\VMS$COMMON\SYSMGR\ACCOUNTNG.DAT;1", and then ReadFile requests are sent, with data being returned. BUT, then other CreateFile / ReadFile requests start coming through!

The Process Monitor trace is odd, too. I filtered to path contains ;1 (a VMS thing). A previous run showed the path as t:, but it switched to a device. I originally used r:, but odd cached files / directories from another disk image kept coming up / being queried. That is odd, too.

Any ideas? I can post code, but it is in vb.net..

Thank you!

[Liryna]

Hi @W6AKP ,

This feels like there is invalid or incomplete (any of the requested fields) data returned through FindFiles or GetFileInformation. Is the requested name at least correct (expected for you) ?
Try to get the windows properties on the file correct by spying the request returning invalid data.

[W6AKP]

Hello @Liryna ,

Thank you for the reply!

I went in a added a bunch of extra checks, and cleaned up a few bugs on my end, but they mostly affected deeper directory scans. I now double check the passed in filename, vs any "handle" I place in the CreateFile call. Similar to FAT, each directory has a back link (In VMS, they are File Headers, and they all have back links to parents), so I back link and regenerate the filename path, and verify with the passed in filename. I got that nailed down.

As a test, I opened the 2nd file in my test folder, this time V:\VMS$COMMON\SYSMGR .

The first file is ACCOUNTNG.DAT;1 , 2nd is AGEN$NEW_NODE_DEFAULTS.DAT;1

When I right click, and get properties of the 2nd file, I trace:

CreateFile: \VMS$COMMON\SYSMGR\AGEN$NEW_NODE_DEFAULTS.DAT;1: access=ReadAttributes, mode=Open, opt=None, IsDir=False
*****Open for Info
GetFileInformation: \VMS$COMMON\SYSMGR\AGEN$NEW_NODE_DEFAULTS.DAT;1
Ret< Name: \VMS$COMMON\SYSMGR\AGEN$NEW_NODE_DEFAULTS.DAT;1, Size: 520

The returned size is 520 (I print that right before returning )
Console.WriteLine(" Ret< Name: " + fileinfo.FileName + ", Size: " + fileinfo.Length.ToString)
Return DokanResult.Success

Windows then reports

The file size reported, is of ACCOUNTNG.DAT;1 ...

So, I followed your suggestion of spying, and I see this..

When I dig into the event I see

I don't know what 1: is, but it references ACCOUNTNG.DAT;1 !

Here is the directory listing (The top of it)

I might just make a flat file report of the disk info, with paths and dates / sizes, and just try to work from sorted dictionaries, to sort this out.

Thank you very much for your time, help, and thoughts,
Ben

[W6AKP]

Ok, I made some progress.

When I tried to do the following from the cmd prompt, I got all files typed, EXCEPT login.com...
type "V:\TCPIP$FTP\LOGIN.COM;1"

And a trace resulted in these being returned.
0: TCPIP$FTP_RUN.LOG;79
1: TCPIP$FTP_RUN.LOG;78
FileInformationClass: FileFullDirectoryInformation
3: TCPIP$FTP_RUN.LOG;76
4: TCPIP$FTP_RUN.LOG;75
5: TCPIP$FTP_RUN.LOG;74
6: TCPIP$FTP_RUN.LOG;73

So, I ended up implementing FindFilesWithPattern, with basically the same code as FindFiles, but I do strict match, or "*".. Not great, but it helped debug that. I now get proper proper file properties in Windows.

The command prompt cannot do a DIR, or switch to that drive / folder. But, type works. Notepad still can't open the files, but npp can.

I wonder if the $ present in the files / directories is screwing up matching.

--Ben

[Liryna]

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
$ should be fine.

I must say it is hard to follow and to help you 😢 I am sure you will be able to get this through and I am happy to help if you have generic questions that can be matched with one of the samples.

[LTRData]

So, I ended up implementing FindFilesWithPattern

That is almost always how people solve these kinds of problems.

The command prompt cannot do a DIR, or switch to that drive / folder. But, type works. Notepad still can't open the files, but npp can.

Then you probably have some issues with handling memory-mapped requests. These can turn up outside of CreateFile/Close/Cleanup calls and you will for example get requests directly to ReadFile/WriteFile with a file name. You will need to handle this scenario, in most cases by detecting that you do not have a context (from CreateFile) when ReadFile and WriteFile are called.

I wonder if the $ present in the files / directories is screwing up matching.

No, not likely.

[W6AKP]

Hello @LTRData!

Ok, after more digging and messing around. I removed the VMS file versions for files with the max version. Makes them cleaner. That was aesthetic..

Here is another chain with ProcMon...

That damn 0xc0000000 has been bugging me. Also, I NEVER see a read without a context. I have a breakpoint there, to try and find it.

So, looking through my code, I find this gem.

`Public Function GetVolumeInformation(<Out()> ByRef volumeLabel As String, <Out()> ByRef features As FileSystemFeatures, <Out()> ByRef fileSystemName As String, <Out()> ByRef maximumComponentLength As UInteger, ByVal info As IDokanFileInfo) As NtStatus Implements IDokanOperations.GetVolumeInformation
volumeLabel = Vol.HomeBlock1.VOLNAME.TrimEnd
features = FileSystemFeatures.None
fileSystemName = "DECFILE11B" 'String.Empty '
maximumComponentLength = 256

Return DokanResult.[Error]

End Function
`

Other than the obvious problem of being VB, I was returning Error.. Change that to Success, and LOTS of problems go away. The volume name shows up, file system type, etc. Oddly, the free space and size were correct before.

So, I'll keep playing, and making things work better.

Thank you to @Liryna and @LTRData for their time. And, I'm sorry for this stupid error. I had a feeling it was something dumb. One messed call ruins it all!

I suppose, could someone patch RFS.cs?

public NtStatus GetVolumeInformation(out string volumeLabel, out FileSystemFeatures features, out string fileSystemName, out uint maximumComponentLength, IDokanFileInfo info) { volumeLabel = "RFS"; features = FileSystemFeatures.None; fileSystemName = string.Empty; maximumComponentLength = 256; return DokanResult.Error; }

Thank you, again! I was looking at pulling some code from long ago from FTPDrive, which is floating around out there, for this same idea. This project is awesome!

--Ben

[LTRData]

Awesome! Sometimes it is simple things that are easy to miss!

[Liryna]

Thanks @W6AKP for pointing the issue 👍 dokan-dev/dokan-dotnet@b80f729 I must say RFS is not the best example to base a new filesystem 😢