DAZ Studio Pro 4.6.2.118, DIM questions
DavidGB
Posts: 565
MBusch said:
As Rogerbee said "Just because this and the DIM exist it doesn't mean that you HAVE to use them.". I would ask: why not? I use DIM all the time to install and update my products. It works like a charm.I don't use it for a simple reason: it requires a folder and files in and therefore access to the Public Documents folder, and nothing on my system is allowed access to the Public Documents folder. The DIM should not REQUIRE that location (especially for things that should go in App data); it should be user configurable. In fact I noticed that in the DIM log files on each running it reports setting that location, which implies to me it OUGHT to be configurable - if it's hard coded with no facility for a choice why is the log showing it? But the option for the user to configure it has either been disabled or hidden. Until and unless DIM does not require access to Public Documents it will never be used on my system.
The CMS is another amazing DS feature that is sub estimated by so much users.
I don't use it and the Smart Content pane for the same reason I didn't when it first appeared. The vast majority of my content, collected since 2004, is not from DAZ and has no metadata, so doesn't show up in Smart Content. Manually creating all that metadata is well beyond my abilities. I'm disabled and can only use the computer for short periods of time - manually metadata-ing my content is a completely impossible and inconceivable task for me. Even if I was still healthy and could use the computer as I used to, the task would still be too vast and tedious to contemplate. So, I use content library and a folder structure in which I can find all of my content, rather than Smart Content in which I can only find a fraction of it.
To DAZ ... when you've fixed the problem with the toolbar, you really must make it available in installer form. Don't just make it a DIM only release as a beta.
On a positive note this is the first DS4.anything update version since the first private betas which has installed for me in one go without error messages and requiring me to manually monkey with files before managing a completed installation. Then again, I haven't run it yet ...
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Hi David, before all, you are one of my heroes in the community and I have so much respect for your opinion, but I think sometimes we stand hard in a complaint or in a point of view, and forget what for. While I agree that the Public folder in Windows and its counterpart, the Shared folder on OS X, are not the best place to hold the DIM configuration files, as you can configure where the package install files are downloaded, I cannot see this as an obstacle to use DIM.
Nothing has access to the Public Documents folder on my machine (or the other Public folders), as part - and only one part - of an integrated and designed overall security/protection strategy. All access, read and write, is blocked and locked. Nothing to do with DAZ; everything to do with the way I choose to protect the security of my system. Using DIM as it is and has been would require me to remove that general block. I will not do so. It is fine for DAZ to recommend the use of it as a location; it is fine for them to make it a default; it is NOT fine for them to require it.
Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.
Actually, that is the MS specified location to install 'shared' content...items meant to be used by all users.
Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.
Recommended to shared content. It is not mandatory. Anyway, the DAZ3D\InstallManager folder which holds configuration files as filters, manifests, and settings, which are not content files, should be at \Users\All Users\AppData in Windows and to the counterpart at /Library/Application Support in OS X.While we all think of the term "Content" differently than the rest of the world because of the software we use, Content does not just mean Victoria 6 and everything she wears, her hair and all her friends. Filters and Manifests are generally considered content, settings may or may not be content.
Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.
I am not saying manifests should be in appdata - documents is fine, But not having to be in specifically Public Documents any more than My DAZ Library. You should not be trying to force things to be installed as shared content. It's up to the user what should be shared and what not. Poser recommends Public Documents for the main runtime, but doesn't force it, which is correct behaviour. You do the same with the My DAZ Library. What possible reason/excuse do you have for forcing these DIM files into Public Documents rather than allowing the user options, as with the MY DAZ Library?
Anyway, there are good reasons why a user such as myself might choose to disable the public folders, and it is not for you to say I must trash my carefully chosen and configured system setup just for you. I have many, many other programs from a wide variety of sources, and not one of them forces use of the Public folders, although many will use them if the user wishes, and a fair few will use them by default unless the user chooses otherwise. I choose otherwise. And the authors of the operating system say this is one of the places they CAN be, not SHOULD, and definitely not MUST.
Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.
I am not saying manifests should be in appdata - documents is fine, But not having to be in specifically Public Documents any more than My DAZ Library. You should not be trying to force things to be installed as shared content. It's up to the user what should be shared and what not. Poser recommends Public Documents for the main runtime, but doesn't force it, which is correct behaviour. You do the same with the My DAZ Library. What possible reason/excuse do you have for forcing these DIM files into Public Documents rather than allowing the user options, as with the MY DAZ Library?
Anyway, there are good reasons why a user such as myself might choose to disable the public folders, and it is not for you to say I must trash my carefully chosen and configured system setup just for you. I have many, many other programs from a wide variety of sources, and not one of them forces use of the Public folders, although many will use them if the user wishes, and a fair few will use them by default unless the user chooses otherwise. I choose otherwise. And the authors of the operating system say this is one of the places they CAN be, not SHOULD, and definitely not MUST.That is where Microsoft says they belong, since they are intended to be used by all users of the computer.
o_O
I didn't even know there was anything under Public Documents. I never use it. lol
Maybe add in a "install for all users or just this user" option upon installation?
Found some empty folders and game saves though. lol
Now I am not saying that an argument for them being in Appdata couldn't be made, but where they are is definitely one of the places where the authors of the Operating Systems say they should be.
From the "File System Programming Guide" at Mac Developer Library:
The user domain contains resources specific to the users who log in to the system. Although it technically encompasses all users, this domain reflects only the home directory of the current user at runtime. User home directories can reside on the computer’s boot volume (in the /Users directory) or on a network volume. Each user (regardless of privileges) has access to and control over the files in his or her own home directory.
The local domain contains resources such as apps that are local to the current computer and shared among all users of that computer. The local domain does not correspond to a single physical directory, but instead consists of several directories on the local boot (and root) volume. This domain is typically managed by the system, but users with administrative privileges may add, remove, or modify items in this domain.
The network domain contains resources such as apps and documents that are shared among all users of a local area network. Items in this domain are typically located on network file servers and are under the control of a network administrator.
The system domain contains the system software installed by Apple. The resources in the system domain are required by the system to run. Users cannot add, remove, or alter items in this domain.
Figure 1-2 shows how the local, system, and user domains map to the local file system of an OS X installation. (The network domain is not shown but is similar in many ways to the local domain.) This figure shows the visible directories that the user might see. Depending on the user’s system, other directories may be visible or some of the ones shown here may be hidden.
OS X Library Directory Details
The Library directories are where the system and your code store all of their related data and resources. In OS X, this directory can contain many different subdirectories, most of which are created automatically by the system. In iOS, the app installer creates only a few subdirectories in ~/Library (such as Caches and Preferences) and your app is responsible for creating all others.
Table A-1 lists some of the common subdirectories you might find in a Library directory in OS X along with the types of files that belong there. You should always use these directories for their intended purposes. For information about the directories your app should be using the most, see “The Library Directory Stores App-Specific Files.”
Table A-1 Subdirectories of the Library directory
Subdirectory: Application Support
Directory contents: Contains all app-specific data and support files. These are the files that your app creates and manages on behalf of the user and can include files that contain user data.
So my argument is that filters, manifests, and settings are not user files, but they are app managed files. They are created and modified by Install Manager, not by the user, even so they are result from user interaction, the file's content is not a user creation. I think the Install Manager folder would be better making company to the Content Management Service folder located at /Library/Application Support. I really can see a solid argument to be where it is.
DS and DAZ are not the single developer putting this kind of stuff in the Shared folder as you will can see on the screenshot below, someones at last put them on a non documented /Library/Application Support, but this does not make sense at all. My DAZ Content folder, as it shows in the screenshot, was always on the Shared folder by a personal choice and pre dates DAZ Install Manager existence.
Anyway, I can live with this and I much prefer to ask again for visible icons on Mac menus (see the screenshots). In DS for Windows you get the icons in menu so much visible than in the DS for Mac. The icons in the menu are clearly visible in the Windows version, and so pale in the menu for the Mac version. I would like to get visible icons in the Mac version. They would be as the Look At My Hair icon. What do you think? It is just an aesthetic and cosmetic complaint, but DS users are visual thinkers. Do you think this request make sense?
That stupid "Public Documents" folder is on C: ... my C: drive is an ssd - do you want to know my opinion about things that insist on being installed on C:?
If you want to, just imagine very bad words.
The only option is creating Symlinks
http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
Vewy funny - or not.
My C: is an SSD as well and I prefer to keep it to just the OS, drivers, and security software (for scanning speed). I even took it as far as completely remapping My Documents on the OS level to be a folder on E:. I'm not too worried about it being in there as my appdata is still on C: too. For now I'll just look at it as appdata in a crappy location. lol
Right now, I've only got 1 symlink going, and that's Bryce content. I pulled it out of the program folder and put it on F: where the rest of my libraries are.
Hmm,
The whole 'no metadata' thing is a good point, and one I hadn't actually thought of. Quite a chunk of my runtime is characters and clothing that have come from Renderosity and were made for Poser, so, as you rightly say, they won't have metadata. So, in that respect alone, there's not much point in me using Smart Content, as I really don't have that much smart content!
This is why you're always good to have around!
CHEERS!
You are missing the point. Obviously I have not explained myself properly.
Installing on our systems there are two different situations amongst your customers/users.
1) Installing on a system for multiple users with multiple user accounts where the software is to be used by all. In this case it is quite right and even expected for you to use Public Documents - that's what it's for (leaving aside the question of whether it is really application data or content). Although even in this circumstance allowances should be made for those who do not wish such data files to be stored on their C drive but haven't gone through redirecting Public Documents to another drive.
2) A system for a single user with a single user account. The default documents folder to use in this case is My Documents, not Public. And a user with a computer personal to them, which no-one else uses, with absolutely no requirement for sharing files between accounts, may have one or more of a number of perfectly valid reasons for not wanting anything to use or even potentially have access to the Public folders, from simple neatness/anti-sprawl/simplicity - not having to remember yet another location things might be when looking for them or to have to keep an eye on - right through to being part of an integrated security strategy giving a higher level of security than is possible on a multi-account system due to the simple nature of having multiple accounts.
I have installed and used many hundreds of programs/applications on Windows 7 and previously XP. Quiet a few of them had a requirement, if being installed for use by multiple users on a multiple user system, to use locations like Public Documents. But not one of them - NOT ONE OF THEM - forced it. All of them either gave an 'Install for All users/Install for single user' choice during installation - creating a directory in Public if 'ALL', and in My if 'Single'; or they simply gave a user selection of directory to create the folder in, perhaps with a default of 'Public' showing and used if the user doesn't change it. (Oh yes - quite a long time ago, there were a couple, produced by spotty teens in bedrooms who simply instructed what to edit in what .ini file to use a different directory; but they were the exception, and even then they did still provide the means to choose, if clumsily.) Not one - NOT ONE - forced use of Public Documents on Single user systems.
And that is the point here. You have users installing to multi-user systems, and users installing to single user systems. It's OK, fine and expected for you to follow normal practice for installation for use on a multi-user system. But it is running against best, normal and expected practice for you NOT to allow for people installing on single user systems. And on single user systems you cannot and should not assume you can have access to use Public Documents. That you do is completely appalling, and indeed baffling. OK forgetting initially I suppose, though as a professional company, not a teenager in a bedroom it's surprising. But after the first public release you were called on this by a bunch of people, amongst whom I was only one. And the fact that you haven't fixed the software, despite a number of further releases, to follow normal, never mind best and expected practice for installation on single user, single user-account systems is just incomprehensible. I can only think of two possible reasons, and neither are very flattering to DAZ.
So the point is that there are different requirements and standards when designing software to install on multi-user machines and single-user machines. DIM is currently designed for multi-user machines, but that does not mean it is OK for single user machines, or that you can ignore single user machines and the requirements of their users - you need to allow for that, and have signally failed to do so. It's not impossible; it's not even hard. Everyone else from big companies to teenager-bedroom-freeware manages to do it; YOU manage it with DS and the rest of your software, so why the heck can't you pull your finger out and get it adapted to meet the standards for single users and their varying needs as well as multi-user setups.
Now -
I am a single user with a single user machine, and I will not install DIM because it does not work on my machine - because it has not been designed to the standards for single user use, and requires access to a location it has no right to expect access to from a single user in a single user environment and does not use the location the standards for single user use dictate. Unless you are saying that DIM is ONLY for multi-user environments - in which case it should be clearly stated that that is the case on the product info pages on the DAZ website. Otherwise - SORT IT OUT ACCORDING TO THE STANDARDS FOR SINGLE USER INSTALLATIONS. It's not hard. Everybody else manages it; and even DAZ has managed it with their other software.
Just on the is it or isn't it application data question - really you should not try saying that the stuff in there is actually content, not application data when the DIM program ITSELF, on starting, writes in its log.txt file:
Application Data:
Location = C:/Users/Public/Documents/DAZ 3D/InstallManager
So clearly DAZ DOES think it is application data. And therefore a breaking of programming standards. But I would agree that SOME of it is not really application data, so you really ought to move the actual application data to where it should be, and have the program internally call the location for the manifests etc something else. But I'm not that bothered by that. I AM extremely bothered by the continual failure to abide by standards for single user use when installed on a single user system. And as nothing on my system has access to Public Documents (or the other Public folders), which is a perfectly reasonable state for a single user system, configured for very good reasons, I cannot run DIM.
You are missing the point. Obviously I have not explained myself properly.
I understand your point entirely. The point you appear to be missing is Microsoft says that is where the files belong on Windows, so that is where they are installed.
If you believe Microsoft "best practices" are a security problem, that is between you and Microsoft. Unless/until Microsoft agrees with you that it is a Security Risk, and advises programmers change where things are installed, they will continue to be installed where Microsoft says they belong.
Gotta agree with David on this one Spooky. MS is assuming there are multiple users on any given computer but most of us, that I know, have our own and if it makes your user base uncomfortable having stuff installed into the Public folder set up then you might want to offer an option like many other installers do.... "Just you" where most stuff will be installed to My Documents or "Everyone" where the content and other needed files will be installed to the Public folders.
And as already pointed out "Public" is only shared by users on the Machine, regardless of the number of users onthe machine, even if that number is only 1 unless the System Administrator says otherwise.
That's the most ridiculous thing I've ever heard. MS does not mandate, only the end users make those decisions. LOL
And if 99.99% of the users don't know/care...it's effectively a mandate, anyway.
Because, most users never deviate from the defaults (even those that know better...like the fact that one of the reasons for the Target data swipe was a DEFAULT PASSWORD!!!)...so, in essence, the 'suggestion' becomes the 'mandate'.
And in the end, does it really matter, whether or not there is a locked down User account and an Admin account...because, it seems that the malware STILL has access and gets installed, anyway.
Maybe something has changed. From Certification requirements for Windows desktop apps:
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user
10.1 Your app must be installed in the Program Files folder by default
For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.
...
10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData
10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\AppData
The Install Manager folder holds app data, not user files. Following this logic, It makes sense put it in the same \ProgramData\DAZ 3D path, which holds the CMS and Studio4 data folders. As I said, I can live with this, but maybe you can review this point.
Best practices for whom?
Are you doing everything MS says?
Good luck with that.
Because if I left my Windows7 in the Default as Microsoft wants to install it, my SSD would die fast.
That is why there are a lot of pages on the internet how to configure Windows for an SSD harddrive.
This is just one example why Microsoft is not always right.
Personally, I want a CHOICE.
Make it default, but give me a choice.
Filters are definitely user data, not app data, they are user built, user defined and user saved. An argument that Manifests are not user data could be made, but it also, clearly fits the definition of User Data (it varies with each user's store account and is User unique, further a user's action with the program generates the files.)
That only leaves settings, which is more likely Program Data, but can also be argued that it is also user data. Easier to troubleshoot and provide customer service when it is all in one place. (Also note that Public Documents is easier to remap than appdata.)
Since Install Manager is supposed to be usable by all users on the machine, that means it goes in Public Documents.
Best practices for whom?
Are you doing everything MS says?
Good luck with that.
Because if I left my Windows7 in the Default as Microsoft wants to install it, my SSD would die fast.
That is why there are a lot of pages on the internet how to configure Windows for an SSD harddrive.
This is just one example why Microsoft is not always right.
Personally, I want a CHOICE.
Make it default, but give me a choice.
You have a choice. Public Documents is not required, by the OS, to be on C.
Edited for crossposting ...
This is the part DAZ doesn't seem to get, some of us users are control freaks that want our computers set up a certain way. I have never installed programs to the Program Files folder when I can help it. I've finally got CMS and its database to run reliably by not putting in its default install location. And with many new computers having SSD OS drives being able to control where files and folder are located is even more important.
This is the part DAZ doesn't seem to get, some of us users are control freaks that want our computers set up a certain way. I have never installed programs to the Program Files folder when I can help it. I've finally got CMS and its database to run reliably by not putting in its default install location. And with many new computers having SSD OS drives being able to control where files and folder are located is even more important.Note you can install the app to the location of your choice.
We get it, we deal with customer service issues on a daily basis because someone decided to install something someplace where it can't work.
More commonly, what they have is installed all over the place in an inconsistent manner, and it is our software that is "broken" because they don't know what they did or where they installed it.
Putting it, consistently, where we put it, is easy to remap if you need, or even just want, it on a different drive, without the potential of breaking everything when something changes.
And I think, that is were the 'problem' lies...it's the simple fact that 99% of the computer users don't know enough to make those choices, so what is a developer to do?
Cater to that less than one percent that does know and is able to make it work the way they want...at the expense of the rest of the users who would find it nearly impossible to do anything and give up in frustration (that's the main problem Linux faced for years)?
Face it, in order for software to be successful, it MUST cater/be usable by the least capable users, with minimal fuss...so that usually means doing things entirely opposite of what a knowledgeable/capable user would do...and even that is often restricted by illogical (to many) OS imposed 'guidelines'.
Yes, I agree that having a 'single user' install would be a nice option, that would allow something that now takes a lot of configuring, both at the OS and program level to achieve, but it probably won't be used except by a handful of folks and be very likely to confuse/frustrate/cause problems for the masses. So is it worth the time/effort/expense?
How many ran the old BitRock installers from the command line...with options?
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user
10.1 Your app must be installed in the Program Files folder by default
For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.
...
10.3 Your app data, which must be shared among users on the computer, should be stored within ProgramData
10.4 Your app’s data that is exclusive to a specific user and that is not to be shared with other users of the computer, must be stored in Users\\AppData
If you stand that your statement above is true, I would ask, why is Studio4 folder in \\Disk\ProgramData\DAZ 3D as they hold user files as Custom layouts?
I agree, custom filters created by the user are user data, so they can be stored /Users//AppData. The point is that filters and settings are not user documents as a Scene file is, they are just user data generated by the user upon application UI interaction, but they are data not documents. I mean, I cannot move this files from where they are and I cannot open those files to manipulate them. Well, I can if I could understand how to edit XML, but they are not targeted to be modified and re-saved.
Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)
I quoted 2 documents, 1 from Apple and 1 from Microsoft, and none of them make any mention to store app data on the Shared folder in OS X or Public folder on Windows. There are no mention about store data in those folders in both sites. In fact, both developers state similar concepts about user common data and user specific data:Yet the quotes are for Application Data, and the data we are discussing is not Application data but user data.
Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)
So, may I request to have an option to store my user specific app data where I would like?
Let me try another approach. I am sure there are a lot of higher priorities for the developers, but may I request that Install Manager folder location be moved to the suggested paths? I also sure that you will not get one single user complaint about this move and the peace will reign in DAZland ;-)
So, may I request to have an option to store my user specific app data where I would like?
Again this is not application data.
You can request whatever you like, that does not mean your request will be granted.