MacOS Ghost dsf files - please help

I have noticed several threads concerning this issue for Windoze, but I have not found fixes for OS/X.
My case may be somewhat unique due to my Hardware /Software setup. I am running DAZ Studio 3D in both OS/X and on my Bootcamp drive in Windows 10. My "My DAZ 3D Library" is on my NTFS Bootcamp partition.
I make this writable for the Mac OS using TUXERA and NTFS For Mac (I used to use a 3rd exFAT partition to share the My DAZ 3D Library folder, but that actually caused far worse problems)
I used to run the Windows 10 version of DAZ from both Bootcamp and Parallels 15 but the last couple of DAZ updates have made the rotate and panning navigation impossible...( hope there is a fix soon)
...anyways ...the Windoze version does not have any issues finding the .dsf files, only when I run DAZ from OS/X. Same files, same library. I don't think it is a conventional permissions issue.
While attempting to fix this issue I managed to delete the OS/X database and "lost" all of my DAZ assets (oops). I have reimported the Metadata and that has restored all of my DAZ content.
Nearly all of my 3rd party DAZ format content suffers from this issue now. I assume I will have to reinstall all 3rd party content, but I already tried that with my "problem" content and still have the issue.
I have checked and reset the permissions in Windoze several times, both the entire path and the individual "ghost" .dsf files, from OS/X and from Windoze10, no effect.
Please see the attached screencaps:








Comments
Update 8/22/2019
I was able to repair my botch-up by copying the cms folder from my windoze install of DAZ and using it to replace the MacOS cms folder. Magic !!! All my assets restored and working EXCEPT the ones I was previously having issues with, which are still working fine in the windoze version. (see previous post attachments)...
Sooo... that means the issue is NOT caused by a corrupted cms. Exact same folder contents work in Windoze and not in MacOS.
Now I am wondering if this was caused by incompatibility with update to OS/X Mojave??? I have another Macbook pro to try that out on when I have a little more time.
Right now I am dead in the water, I need these exact assets for a project and the PC version is unusable too, due to "jumping mouse in viewport issue" whenever trying to pan or rotate perspective view. I am going to try reverting to using a Windows7 VM where everything worked before and see if I can at least get functional again!
Just a thought if someone with more DAZ savvy than me is listening...
What if this inability to find the dsf files is related to capitalization errors in the path? I know some software is case sensitive...and some is not. Some disk file systems are case sensitive and some are not...all it would take I think, is one piece of software in the chain that IS case sensitive to cause problems if the file path is not consistantly designated in all locations. This would then be an issue that could be corrected by editing the source files for the assets... but I could see where this might need a script to catch all the locations where this information is recorded...somewhat beyond MY skillset.
Never have your Connect library go to your regular library. If you can see either the "data" or "runtime" folders in your Content Library pane you have something set up wrong.
APFS and HFS/HFS+ can be either case-sensitive or case-insensitive. By default, they're case-insensitive, as are DazStudio (at least through v. 4.10d) and ExFat, so it's unlikely that case is the issue.
For starters, Your DAZ Connect Library should be in its own folder & not in your main Library Folder. Having your Connect Library inside your main library will confuse Studio when its looking for files.
Do you have another drive mounted that could have a similar path after "Documents"?
I usually work on my Mac in a folder that's "MacHD/Users/Tango/Documents/TangoAlpha/Project/"
But for rendering, I share the "My Documents" folder on a PC across the local network as "/Documents/TangoAlpha/Project"
For 100% sure I know that Photoshop will save to the network "project" folder even though I specify very carefully the local one. It seems to ignore the part of the path before "Documents". I wonder if DS is doing something similar here, and it's actually looking in a different place to where you've specified? Just a thought . . .
Alternatively, maybe your bootcamp partition has somehow got mounted twice? I've had that happen, especially after something crashed or didn't shut down cleanly. It'll give the kind of effect you describe.
Yeah, actually I think I set up my APFS as case sensitive. TangoAlpha all is set up on 4TB SSD as 2 partitions: MacOS and Windoze10. I tested my old 2013 Macbook pro and it does not have the issue*, I am now trying to determine which of the differences in the systems is the critical one. Running High Sierra instead of Mojave, My DAZ Library is on 3rd ExFat formatted partition, Nvidia graphics card etc. I don't think it has the Windoze jumping mouse issue either, but I am having other Windoze issues with it right now so I can't verify that. Thank you everyone for the input, I will check my library location and structure as well as these other leads and post when I have more answers.
*SSD on the old mac is only 1TB so it has insufficient HD space for my needs...also Bootcamp died and it is a real pain to get Bootcamp up and running with 3 partitions
jestmart
After considering your response, I find the following apply.
I don't even use the connect library, and I always do my DIM installs offline. I also have no issues with the data or runtime folders showing up in my content pane.
However, in the My DAZ 3D Library folder, I do find two data folders, two runtime folders, two people folders etc. one capitalized and one lower case.
So I am still suspicious of a path error caused by capitalization inconsistencies, especially since only specific parts of specific assets are affected.
Thank you for your input.
TangoAlpha
I don't think so, but I am not 100% sure that MacOS DAZ is not creating a local folder on the APFS partition, that would then be causing me path issues.
mclaugh
Isn't NTFS case sensitive? That is where the My DAZ 3D Library folder is located. Also, I believe all the files at issue are 3rd party, so DIM can't install them, they are installed by manually copying the "data/Data" "runtime/Runtime" folders etc. into the My DAZ 3D Library thus the file system, not DAZ determines the filepath/capitalization. This I would think could cause DAZ a problem if it choses the wrong path for the dsf file of a specific asset.
NTFS is case-sensitive, but the default for the Windows API for file access is case-insensitive to maintain backward compatability with earlier versions of Windows. From Wikipedia:
[quote]The older Microsoft Windows filesystems VFAT and FAT32 are not case-sensitive, but are case-preserving. The earlier FAT12 filesystem was case-insensitive and not case-preserving, so that a file whose name is entered as readme.txt or ReadMe.txt is saved as README.TXT. Later Windows file systems such as NTFS are internally case-sensitive, and a readme.txt and a Readme.txt can coexist in the same directory. However, for practical purposes filenames behave as case-insensitive as far as users and most software are concerned.[/quote]
Case-sensitivity is optional in Windows 10. To enable it, see How to Enable Case Sensitive File and Folder Names on Windows 10.
I manually install EVERYTHING in my DAZ library by dragging-and-dropping the contents of the unzipped archive onto the MyLibrary folder. (Never used DIM and never will.) There's only one data, runtime, texture, and template library, and everything installs in the correct location, regardless of the case of the folder name in the unzipped archive.
mclaugh
OK, so it is possible the issue is: in the process of installing the assets, the path created is different than the "relative" path references (not sure where those exist) that the asset author has built for DAZ to locate them? or to put that another way... if the artist that created the assets was not consistent in the capitalization of the asset names and the folder names an error in the path references could be introduced by the install under certain conditions?
I also assume from your comments, that you are making your installs under windows only? It is the dual operating system structure of my setup that appears to complicate my installs. I have had no issues with any of the assets installed to this My DAZ 3D Library folder, with DIM Windows and DIM MacOS. It is only the 3rd party Assets that I have installed by "drag n' drop" in windows and using MacMerger from MacOS, that have had issues with some Assets, and looking back it is only when I access this My DAZ 3D Library folder from the MacOS Daz application that the issue manifests...so my conclusion is, that I must either correct the paths and the path directories to be in consistent cases, or somehow make DAZ retrieval of the files in MacOS case-insensitive, perhaps by formatting both of the partitions specifically as "case-insensitive"?
Possibly I can correct this by reinstalling my entire content library under windows?
This was working fine for me until recently, when I have had issues with a small number of 3rd party files. Nevertheless these files are important to current work. I need to address the issue and prevent it from recurring. I really believe that this is the issue, due to the redundant data, people, props and runtime folders. I believe that setting up so that all the file systems are non-case-sensitive will accomplish that goal. This should also make things easier when I build my Windoze based "renderbeast" server...
I'm encountering this case-sensitivity issue myself (on Mac with an extarnal drive) and I seem to be solving it by creating aliases for the alternate-case directories. (So far it seems to work).