Creating a share per installation is erroneous and ridiculous. The issue isn't the customer producing pathes too long, it's the fact Autodesk is producing pathes too long.
In our case, putting the installation folder to a share would only save 19 characters of 255 (bypassing two folders), or less than 7% of the characters.
I tried these 2 paths for the 3DS Max Design 2013 AdminImage folder location of which the first failed and the second succeeded:
The first is 58 characters and the second 49.
So for those of you installing 3DS Max Design, you can use at least 49 characters to designate where your AdminImage folder is but 58 is right out.
So Travis, you are saying I should do this:
But really the paths are longer because I have to include the product's year as a subdirectory (+5 characters) or multiply the number of shares with the year as part of the name (+4 characters).
So is this long list of shares an advantage over browsing through a logical hierarchy of subfolders like \\server\software\company\product\year? (This doesn't get anywhere near 243 characters as you are implying some of us doing. It probably could be done in less than 75 but the 50 Autodesk gives is tight.)
When Autodesk creates file names like "Create Universal Constraint - PxCreateUniversalConstraintMS_PhysX - 32.png" (75 characters where 1/2 are repetative) and uses the exact same name for both a child and parent folder like "...\Essential_Skills_Movies\3dsMax_Design_2013\de
Yes, that is exactly what I am saying to do. And that is what I do - thus I have never had any of these problems. I agree that the Autodesk filenames are long and ridiculous and they need to be changed. But it is what it is. This is how to get your deployments working. Whether you have one share with multiple folders to traverse inside, or multiple shares for all the products, it's all the same. One way works, the other doesn't.
Actually both work, just 1 won't work if you go beyond a certain character limit like 50.
I like the heirachy better than your suggestion though because we have numerous software and in that case a flat system is more confusing than a heirarchy. We will just have to stay under 50 characters, which is doable but with extra attention required.
The heirarchy can exist in the same physical folder fashion, just share the last folder with the name. Whether you go to a server and drill down thru multiple folders, or go to a server and see a list of shares, the result is the same. If I wanted to install AutoCAD 2013, I could go to \\servername and then locate the \ACAD2k13 folder. Or I could go to \\servername and then find \APPS\ and then find \Autodesk\ and then find \AutoCAD\ and then find \2013\. Personally, \\servername\sharename makes more sense and it easier. It could still exist at D:\Apps\Autodesk\AutoCAD\2013, but just share out the last folder and send the link out to your users.
It's 6 of one, half a dozen of the other. I mean, it's all how you look at it. Ultimately, the filepath length needs to be addressed. But as for now, this is all we can do as a work-around.
It is 6 of one, half a dozen the other, yes. But as you say it's a matter of perspective. I don't think anyone wants to add their 2 cents to debate with you but to voice their frustration at Autodesk in a public format. As you conceded, there IS a problem with filename length in Autodesk products that exacerbate this situation... so, here we are... people are letting Autodesk know how frustrating it is. Can't it just be left at that?
True, but at the same time, how is it any better for the end user to create a folder structure that consists of multiple characters and many levels deep? I agree that there are some Autodesk filenames that are simply too long, but I also see that too many end users are creating filepaths that are also too long. Thus, the only recourse for this instance, until Autodesk creates smaller filenames in subsequent releases, is simply to create short share paths. Arguing beyond this point is moot.
But we are the ones paying for the software. If we want to have it on a server with a single share that is catagorized and sorted by a folder tree we should be able to.
When you buy a car no one tells you that you can only drive it when you wear blue pants and a hat.
You have an opinion about how folder structures should be created, thats fine but it has NOTHING to do with this conversation. The point here is that the way they have created the software is limiting us and we would like them to correct that.
No, the metaphor is more like a car that is designed to run on gasoline but you'd rather run on electric. There's nothing that can be done during this release except to wait for the flex-fuel vehicle to be released. Thus, the share path length recommendation has everything to do with this conversation because unless you do so, you cannot install it. Period.
Regardless, the limitation is on Microsoft Windows, and not Autodesk. Thus any software manufacture would potentially run into this same issue. Hopefully, this will not be an issue moving forward.
I'd like to bring up the fact that the latest 2013 suite we are rolling out recently is even worse than before.
I was able to shorten a path length with the 2012 suite and get around the character limit. But with 2013, it was impossible so I just created an individual share for it and flipped a birdy at the deployer as it ran.
The fact remains, not only should the installer be double checking path length PRIOR TO STARTING TO CREATE THE DEPLOYMENT but the people actually making the installation packages should be doing it as well.
I doubt it would take one of Autodesk's engineers more than 1-2 hours per product in the suite or several hours to add the path length check to the deployer; and yet it would save hundreds (if not thousands or tens of thousands) of hours of their customer's time dealing with these issues.
But why do that when you can just have a moderator blame the customer everytime the issue crops up on the forums.
I don't see any moderators saying the customer is wrong in this thread except for the OP stating the work-around for the known issue. Anyway, I doubt any customer has spent thousands to tens-of-thousands of hours trying to figure out that a short path share would resolve the issue. It took me 15 seconds to write this. And I've never experienced this issue because I have always adhered to the \\servername\share convention.
The fact of the matter is Autodesk has known about this issue for several releases and refuses to do anything about it. The CUSTOMER is being inconvenienced by it. Fix the thing AutoDesk.
Thank U, that's exactly the point. I've done a bit of development myself and there is no reason that anyone would need filenames 70 - 90 characters long. They know this is an issue so for well now since 2009 for sure from my personal experience. And of course if doesn't error out until it reaches that file, like give me a break, do a check sum on the file path names before actually installing or even simpler yet shorten the filenames. I spent way too many hours have to rebuild packages because Autodesk shear laziness. This maybe would have been acceptable for a version, I get that programmers mess up but 5 years in a row.
You are not helping any of us and you are not contributing anything. Some of us follow this to see Autodesks responce to this, no one cares about yours.
If Autodesk fixed there product than I would have anything to say about it, now would I. And after the hours I had to spend to fix my packages, I am going to complain a little. Trust me I have already made many feedbacks about it.
Autodesk was the one that originally created this post as a response to this known support issue. I am simply supporting the position that this is easily avoidable by following their recommendation. I apologize if my support for the work-around was taken out of context. I agree that steps should be taken to prevent this in the future, but the simple fact remains that this is the fix for now. Furthermore, this is a peer to peer forum. I recommend that you fill out a customer support request in recommending that this be resolved in a future release.
Autodesk is working on a plan to resolve this issue internally. i.e. make paths a short a possible. I have posted a workaround based on this forum post here:
This post refers to an issue with 3DS Max Design in a Suite:
This is a hot topic that should be resolved in a future release.
Search the Autodesk Knowledge Network for more content.
New: Get an Activation Code
Mac OS X 10.12 Support
Windows 10 Support
Autodesk Online Store Help
Serial Numbers & Product Keys
Installation & Licensing
Online Activation & Registration
Network License Administration