Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[carbonide2]

This may be very well a problem with my setup and not ClrMAME itself, but maybe one of you had a similar problem and knows a workaround.

For years I've been using VMware Fusion on macOS (for Intel based machines) with a feature called "shared folder" to make an external drive accessible for scanning. Having exchanged my old Mac mini for a newer model using Apple Silicon, I noticed that the current version of Fusion does not support that feature.

A way to get around is to use macOS's built-in SMB file server and access the files using Windows built-in SMB client. I'm now able to access all the files on the disk from Windows and ClrMAME sees the whole folder hierarchy as documented in the screenshot below:



But running a scan results in the following error:

Code: [Select]

error analyzing . failed due to directory_iterator::directory_iterator: Invalid Signature.: "."
Does somebody have an idea what's going wrong here?

[Roman]

Seems that a std::filesystem::directory_iterator (c++ stl function to run access all files within a folder) throws an exception for "." (the current folder) for whatever reason. I will have a look why it creates that error (since it works on a 'standard' Windows drive :-)). I will check if using "." can be changed or check why it could fail with your setup.

[Roman]

When scanning, clrmame changes to the romfolder and if this succeeds, it uses a directory iterator on the "." (current path).
Maybe you (or clrmame) don't have access rights?
Guess that can be tested when you simply use the rebuilder from that folder to elsewhere. The rebuilder accesses file files via full names since it does a (recursive) directory iterator on the full input path name. That would give an idea if access rights or full path names might be an issue....

[carbonide2]

I don't think it's a permission problem as I can see the files in Windows so ClrMAME should also be able to access them, should'nt it?

This results in the following error:

Code: [Select]

info using already existing xml export
info loading: C:\Users\Charel\Desktop\clrmame\exports\bc03e79e-listxml.xml
info building split view, rebuilder map and destination patterns
info 47966 split merged machines selected
info rebuild start
info analyzing rebuilder source: Y:\MAME\ROMs, please be patient
error analyzing rebuilder source Y:\MAME\ROMs failed due to recursive_directory_iterator::recursive_directory_iterator: Invalid Signature.: "Y:\MAME\ROMs"
info thread pool size: 10
info analyzing rebuilder destination: Y:\MAME\Fix, please be patient
info optimizing
info finalizing and cleaning up
info rebuild end, took 0 seconds
info Done, overall time: 12 seconds
error errors occurred, please check log

Could the fact that the MAME executable is a level lower than the ROMs folder (as you can see in the config) be the source of the problem?

[carbonide2]

Note: I tried to post with an image of the settings used in Rebuilder but the forum software flagged the post as spam.

[Roman]

Yeah the spam bot is annoying...
Well...what I see from the rebuilder log is that you get the same problem with the rebuilder on the files without using the "." but a full path:
Analyzing rebuilder source Y:\MAME\ROMs failed due to recursive_directory_iterator::recursive_directory_iterator: Invalid Signature.: "Y:\MAME\ROMs"
.....and it shows that also recursive_directory_iterator and not only directory_iterator calls have the problem. So it's a general accessing problem, not a "." specific one.

I've attached a 2 textfiles what chatGPT returned on this topic......so it sounds more or less like access rights problems....

You can try to use the old clrmamepro to see if this gives some results on the path, however it doesn't use plain stl::filesystem calls but win32 api calls which (see chatgpt2.txt) might have different additional features regarding network drives). You can also try to run clrmame with admin rights, or -if you're familiar with c++, you can write a very small program which simply uses a std::filesystem::directory_iterator call on your mapped path.....
Generally mapped network drives don't cause problems...but I can't rebuild your specific setup here....maybe some other forum visitor has an idea.

[carbonide2]

If I run ClrMAME as administrator it’s even worse, output consists only of these 2 lines:

Code: [Select]

error can't parse Z:\MAME\PC\mame.exe
error errors occurred, please check log

The user I created for sharing the external disk was another one as either the macOS user and Windows user (all 3 different). I then used the same user name and password for sharing the folder in macOS as the Windows user but that didn’t help either.

[Roman]

"can't parse Z:\MAME\PC\mame.exe"

hmm..interesting....because this means it can't even access a mame binary on your shared drive or run an export for it.
This time no directory_iterator is involved....
So...I'd say.....access rights....I know this doesn't help at the moment. Are you familar with c++? Or got Visual Studio available...then running a small program which simply does some std::filesystem calls on your given path may give some insight on this....

[carbonide2]

I have some programming knowledge but never used C++. If you could send me the binary (bear in mind that I'm using Windows for ARM, but the x86 translation layer is installed) I'd happily try it.

[Roman]

Actually I found some information in the internet that the long path name support could be the reason why it fails on SMB client drives.
clrmame automatically adds \\?\ prefixes to paths so that 32k full path length is supported. Asking chatGPT about possible problems comes back with:

"Yes, there are known issues when using std::filesystem with SMB (Server Message Block) client drives, especially when working with long paths and the \\?\ prefix for long path support in Windows.
Here are some key points that could help clarify the situation:
The \\?\ Prefix: The \\?\ prefix is used to enable long path support on Windows, and it is required when working with file paths longer than 260 characters (which was previously the maximum path length in Windows). This prefix is often used for paths that exceed the traditional MAX_PATH limit, and it bypasses some of the legacy file system API restrictions.
SMB and \\?\: The \\?\ prefix is not always well-supported with network shares, especially when using SMB. Some APIs that work with local paths may not work seamlessly with network paths, particularly when the path includes the \\?\ prefix. SMB file systems may have limitations that prevent proper handling of long paths or the special \\?\ format."


So what I can do is that I compile you a version where no prefix is added....and if that's the reason I could add an automated test for it....so I guess I come back to you in the next days.

[Roman]

ok, here is a custom version (just the exe file) where long path name support is disabled:

https://mamedev.emulab.it/clrmamepro/binaries/shortPathOnly_clrmameUI.zip

would be interesting to know if that is the reason for failing on your SMB client setup

[carbonide2]

Sadly, doesn't work either.

After a restart, I can't even reconnect in Explorer to the SMB share. Unless there's an SMB specialist around here, I don't think we will get this to work.

[Roman]

damn....I thought that long path prefix would be the solution.....thanks for testing

[Roman]

With "I can't even reconnect in Explorer" you mean Windows, not clrmame, right?

Maybe you can also try to use the UNC path of the share directly instead of a mapped drive (e.g. \\fileserver2\roms) ... but before that it should work in the explorer though (e.g. when it needs authorization...)

[carbonide2]

I tried once again but this time with a "real" server (my Synology NAS). It worked right away without any problems.

So it seems it's the built-in SMB server functionality of macOS that is not quite up to par.

[HebelsOli]

Generally speaking, I'm not new to scanning sets, etc.
Using the 'old' Scanner/Rebuilder since 15+ years.

Is it possible that this or a similar iterator-issue exists with USB-attached HDDs in the new clrmame scanner?
Mame-ROMs, -SLs & clrmame 0.31 located on same local USB-attached HDD in their own paths.

--listxml scans are ending with "error   errors occurred, please check log"
--listsoftware scan throwing "recursive_directory_iterator" errors when it tries to access the SL-machine's .7z-files.

i.e.
analyzing .\ngp.7z failed due to directory_iterator::directory_iterator: unknown error: ".\ngp.7z"
analyzing .\orao.7z failed due to directory_iterator::directory_iterator: unknown error: ".\orao.7z"

[Roman]

This sounds a bit like you have compressed all ngp software files into a ngp.7z.
You need a folderstructure like: your_drive:\your_rompath\ngp\ and in that ngp folder you've got the single ngp software list machine, so e.g.
bstars.7z, kof_mlon.7z, etc...(or zip or decompressed).

so for example:
f:\mame\roms\softwarelist (as your one and only rompath which is the
root of the single software list subfolders)
f:\mame\roms\softwarelist\a2600  with
f:\mame\roms\softwarelist\a2600\2pakblac.zip,
f:\mame\roms\softwarelist\a2600\2pakblaca.zip and so on
f:\mame\roms\softwarelist\c64_cart with
f:\mame\roms\softwarelist\c64_cart\4thsarc.zip and so on...

[HebelsOli]

This is not the case.
Each SL item is in its own 7z.

My collection was successfully rebuilt/scanned with your old tool.

That's where I started off using the new one.

When we focus on 'ngp'-set:
I just saw that 'ngp.7z' machine is in 'mame\roms'.
While ngp SL-folder is in 'mame\roms_SL'.

Should I move all SL-folders to ROMS and try scanning again?

Another try would be to make 'mame\roms_SL' the ADD-path and start a scan or rebuild into 'mame\roms'.

[Roman]

You can't mix -listsoftware and -listxml collections when it comes to rompaths.

So assuming you start with a -listxml (standard) mame export, you have rompath(s) and somewhere in it, there is the ngp.7z archive. Fine so far, since the -listxml output lists a machine name="ngp" sourcefile="snk/ngp.cpp" entry with a ngp_bios.ngp rom file in it.

When it comes to software lists, "ngp" specifies a softwarelist which contains all kind of NeoGeo Pocket machines.
So here your rompath should point to a folder which has ngp as a subfolder (and of course others like a2600, c64_cart, etc) representing this software list...and inside that ngp subfolder you have the software list entries for that software list.

So actually you should double check your rompath setup (as described above they should point to different paths).
If you like you can also send me your settings.xml and copy/paste the log output.

You can actually check where your ngp.7z is stored.
The softwarelist "vgmplay" does have a npg machine in it...so in a vgmplay subfolder there should be a ngp.7z, nowhere else when it comes to the rompath (and subpaths) connected to the -listsoftware output.

When talking about -listxml: you should have 1 npg.7z in one of your assigned rompaths.
When talking about -listsoftware: your rompath should have a subfolder named ngp but a ngp.7z should only be in a subfolder vgmplay since it's a part of that software list. Maybe you have some copies floating around elsewhere which cause the problem.

[HebelsOli]

Thanks for the reply.

I will check what you suggested and come back to you.

So far I can confirm:
  'mame\roms' is my classic ROMs folder. (ROMs & CHDs)
  'mame\roms_SL' is my SoftwareList-folder. (SLs only)

  1x ngp.7z machine is in 'mame\roms'.  (No folder ngp there.)
  1x ngp folder is in 'mame\roms_SL'.  (1x .7z per SL item there.)
  1x ngp.7z is in 'mame\roms_SL\vgmplay'.  (plus others like 1941.7z, 1942.7z, etc.)