File path too long to copy or zip

[Doodle Designs]

I've run into a problem that is caused by all the folders that DS adds to the data folder.

Because of the added folders, the file path is so long that I can't copy or zip my product due to the path being longer than the computer can handle, which is limited to 260 characters.

Take a look at the images below. The first one shows the incredibly long file path that DS adds for the data folder. Too long for it even to appear in the address line even with the window width maxed.

C:\Documents and Settings\Administrator\My Documents\DAZ and Poser Content\Glass Block Products\Accessories For Him and Her\data\Doodle Dream Designs\Accessories for Him and Her\Toothpaste\Morphs\Doodle Dream Designs\Base

Because the file path is over 260 characters, the files in this folder won't copy, move, or zip.

The red arrows point to redundant folder names that DS adds, which aggravates the issue.

(Click to enlarge)

The second image shows the errors that happen when attempting to zip the Accessories for Him and Her folder. The yellow highlights how the file path has been truncated at the end because it's too long.

(Click to enlarge)

Also, when I try to copy or move the entire Accessories for Him and Her folder to another location (with a shorter path), it won't because the message says that the file name is too long. I finally renamed the Accessories for Him and Her folder to Access, and also rename another, higher folder to a shortened name, which shortened the path enough that the computer could handle it. I could then copy, move, and zip all the files.

Has anyone ever run into this problem? How did you handle it?

The only thing I can think to do is to develop the products in a place with a shorter file path (even though it means that I can't keep all the files associated with the product together - not only for easy location and backup, but also so if I return to working with the product in the future, I don't have to remember that I'm keeping things in different places.

When researching the problem I found that this limitation frustrates many people who want to keep all associated files together, which sometimes results in deeply nested project structures.

 

[Alisa]

Yes - I have run into this with just things I've installed, and the only way is to make the folder names shorter or put things elsewhere

One option - in Windows you can also move your "My Documents" folder elsewhere so it's not in that long Path:

C:\Documents and Settings\Administrator\My Documents\DAZ and Poser Content

You can move it directly onto the C Drive and call it whatever you want.

It would take some doing but you could also rename that last folder (have to be sure you re-direct DS & Poser to it as your main Library/Runtime area) to something shorter too.

But otherwise, yes, I'd create new libraries that aren't in that long long path.

 

[Morkonan]

...
When researching the problem I found that this limitation frustrates many people who want to keep all associated files together, which sometimes results in deeply nested project structures.

This is why you don't do it like that. (While the character limit can be indexed by OS's like Windows 10, these days, most programs will still not allow that many characters for a directory/file reference.)

First, use "relative" paths when zipping.

Second - Truncate your custom directory names. You don't need them to be as descriptive as you have them, now. For instance:

GlassBlock\HimHer\data\DDDesigns\HimHer\Tpaste\Mphs\Base

I don't do anything with DS, so I don't know any specifics about their required naming structure, if any. But, this looks fine from a general point of view and, at least, gives you an idea of how to solve the problem.

For all else, if the product is for sale, follow DAZ's design requirements for directory structure so it works with their installer/etc. If it's a freebie, however, most people will probably extract it by hand, anyway, and move/copy/paste it where it needs to go.

 

[Alisa]

Second - Truncate your custom directory names. You don't need them to be as descriptive as you have them, now. For instance:

GlassBlock\HimHer\data\DDDesigns\HimHer\Tpaste\Mphs\Base.

for the data folder, fine, but if you plan to sell here, don't truncate names of User facing folders into things that make no sense or are confusing/unclear.

For all else, if the product is for sale, follow DAZ's design requirements for directory structure so it works with their installer/etc.

Only if you plan to sell at DAZ, which I'd figure someone posting here is not asking for advice about . We do not use DAZ's installer, and we do not use the Content folder at the top of the structure.

 

[Doodle Designs]

I decided to develop products in the future on an external hard drive or thumb drive - that way, I don't have to worry about long file paths.

I don't care for the idea of abbreviating every folder name - it messes with my obsessive need to be clear on what I am trying to communicate. Besides this "problem" isn't what I'm doing - I'm just trying to keep everything that's related together in the same nested folder. I really don't like to scatter things about in different folders because when I come back to it after having spent a significant amount of time doing other things (sometimes years), then I have a hard time finding all those scattered files. Where did I put the Hexagon files? The obj files? The Daz Studio files? The rendered images? The documentation files I created? The zip files? Etc., etc., etc. If I put everything into one organized, nested folder, then I only have to find one file, and I've found them all.

The real problem is the way Microsoft is doing things. They need to allow for longer file names. If you can create long file paths, then you should be able access them without restriction. If the paths go over the current limit, you can't even copy or delete them! Why even allow the paths to get that long if it will cause problems? What, they couldn't build in a warning when you try to go over the limit?

I read somewhere that allowing longer path names is coming in a future version of Windows, but who know when that'll be.

Another thing I'm thinking of doing which will, in a small way, help with the path lengths is to change my brand name. I originally started out as just Doodle Designs, but added the additional "Dream" because I discovered that someone had already grabbed that domain name. Well, I've discovered not only have they let their ownership lapse, but I also realize I don't really want to set up my own website anymore. Besides, I like the shorter Doodle Designs better and since I haven't really established the Doodle Dream Designs brand name yet, now would be a good time to change it back to Doodle Designs.

I did sell a few products on Renderosity as Doodle Dream Designs, but that was so long ago that my Doodle Dream Designs log-on no longer exists there.

I wonder - would I be able to somehow change my user name on this forum to Doodle Designs? Is this something a site admin could do, or should I just abandon my current username and re-join with the new name? I haven't made a lot of posts yet on this new forum - and all the many posts I made on the old HiveWire forum are gone anyway.

Any admins out there that can answer these questions?

 

[Alisa]

The real problem is the way Microsoft is doing things. They need to allow for longer file names.

Oh, yeah, I agree!

I wonder - would I be able to somehow change my user name on this forum to Doodle Designs? Is this something a site admin could do, or should I just abandon my current username and re-join with the new name? I haven't made a lot of posts yet on this new forum - and all the many posts I made on the old HiveWire forum are gone anyway.

Any admins out there that can answer these questions?

Pm LisaB - she'll take care of changing your user name for you .

The posts on the old forum aren't gone, by the way, though your name wouldn't be changed there. No images, but the posts are still there:
Forums - HiveWire 3D

 

[Morkonan]

I decided to develop products in the future on an external hard drive or thumb drive - that way, I don't have to worry about long file paths.

I don't care for the idea of abbreviating every folder name - it messes with my obsessive need to be clear on what I am trying to communicate.

Always follow the distributor's instructions for your particular product. (As was said above by Alisa.)

In my opinion only, unless the names in question are materially relevant to what is displayed to the user and the user actually relies on being able to interpret these computer references and extract meaningful information from them, they only matter inasmuch as the computer, itself, can correctly interpret them. So, in effect and in this case, the only thing that matters is what you are trying to "communicate" to the operating system. I do understand one's desire to furnish directories and file references that can be understood by a user outside of the interpretation of an application. But, you have to make practical decisions in some cases. Creating directory structure should be "logically" intepretable, not necessarily descriptively interpretable outside of what is required by the application. For instance, if the application (ie: Poser) uses directory names to communicate to the user, then only those directory names that relate meaningful cues to the user from within the application should be worded to do so if one is concerned about naming conventions and computer intepretation. For instance, if one is coming up with a directory structure for their Poser product (I know nothing of DS conventions in this regard), then the creator's subdirectory within the Character, Pose, Expressions, Hair, Hands, Props, Lights, Camera, Materials directories should have a name that is easily associated with the creator of the product in question. This subdirectory name will be displayed from within the application as a Content Folder and, for instance, its hierarchy within the Content list inside Poser will be determined by.. an old Unix standard, of all things, in most Poser versions. (Please don't lead off your product subdirectory with an exclamation point, multiple capital letters or hard-spaces just to get it at the top! )

In your case, and only in my opinion, I would suggest "DDDesigns" be the subdirectory name you use within these major content directories for a Poser product. However, while you wouldn't necessarily have to change your directory name for the subdirectory under Textures, you could, since that is not a subdirectory that is designed to provide direct, interpretable, information to the user from within the application. (The same goes for the Geometries folder and any other subfolders you might need, like custom morphs, etc) IOW - The subdirectory under Textures is not represented anywhere in the main UI in Poser as an "information-bearing" aid to the User. It is, however, traceable from file references from within the Material room, for instance, or, in some cases, in other tertiary information bearing scripts. (Many 3D artist "Geometries" creators who collaborate with texture artists have products that use the texture-artist's name as the subfolder in the "Textures" directory, for example.)

Why a suggestion like "DDDesigns?" The answer is simple, even when not considering standard computer directory naming conventions - The Content Directory name will most likely be truncated, anyway, by user-selected preferences so that they can maximize viewing area. Shorter entries for subdirectory names that will be displayed as Content identifiers are actually more useful for the user, so long as they are easily interpretable. (It's worth noting that some creators insert a custom graphic thumbnnail within their subdirectory that is displayed as a "Content" entry, even though it is not linked to actual content, just to present the user with an informative message or custom graphic. That's something you could consider, if you wished, as long as the distributor/seller doesn't prohibit it.)

..If I put everything into one organized, nested folder, then I only have to find one file, and I've found them all.

Always obey the product conventions specified by the distributor or the technical development outlines communicated by the application creator. What may be convenient for you may not be convenient for the program or the application users. For instance, if an experienced user is trying to debug working with your product, they may have trouble finding your product's assets if they are organized in a non-conventional manner.

The real problem is the way Microsoft is doing things. They need to allow for longer file names. If you can create long file paths, then you should be able access them without restriction. If the paths go over the current limit, you can't even copy or delete them! Why even allow the paths to get that long if it will cause problems? What, they couldn't build in a warning when you try to go over the limit? I read somewhere that allowing longer path names is coming in a future version of Windows, but who know when that'll be.

Windows 10 expands the naming conventions past the 260 max_path limit. (I don't know the particulars, since I don't "Windows 10.")

Some infos:

Technical Stuffs - Naming Files, Paths, and Namespaces (Windows)
More Tech stuffs - Why does the 260 character path length limit exist in Windows?

The point is - This is "computer." Much of "computer" convention was determined when computers first started to become standardized. These conventions were first limited by the capabilities of the hardware available at the time. Backwards compatibility is a prerequisite for most of what is developed for PCs, today. There is a significant technological conventions lag in creating PC software in order to avoid "orphaning" existing software and hardware and, generally, this is a very good thing.

PS - Hivewire's submission guidelines tell you just about everything you need to know in regards to naming and directory conventions. But, while specific directory structure isn't discussed, it is suggested that your offering follow the standard structure used by DS/Poser so those fairly mutually compatible applications can easily read/use it.

 

[Alisa]

PS - Hivewire's submission guidelines tell you just about everything you need to know in regards to naming and directory conventions. But, while specific directory structure isn't discussed, it is suggested that your offering follow the standard structure used by DS/Poser so those fairly mutually compatible applications can easily read/use it.

Yep, in fact, they MUST follow that structure pretty much. For example, for my OWN Poser files, I move everything into the Character folder, in sub folders that make sense to me. So I have a folder for skirts, and then a Material subfolder with all the skirt materials (well, more complicated than that, but the idea is that the mc6 files are in the Character folder.).

That's fine for me, but a for-sale product here MUST have the .mc6 files in the Material folder.

However, I work with our CAs (particularly with the new ones who may not be familiar with things) to make sure things are done correctly, so if it's wrong, we'll get it fixed

 

[Morkonan]

Yep, in fact, they MUST follow that structure pretty much. For example, for my OWN Poser files, I move everything into the Character folder, in sub folders that make sense to me. So I have a folder for skirts, and then a Material subfolder with all the skirt materials (well, more complicated than that, but the idea is that the mc6 files are in the Character folder.)...

I couldn't function like that.. For myself, I keep everything organized by the standard conventions. I'd have a heart attack if all that stuff was located in a Character folder.

I think some novice content publishers or users may misunderstand the differences between "Content" displays in their targeted application and "directory structure," or how the program, itself, actually works. In some cases, it leads to people placing grouped object files in the same directory as their CR2 as well as the textures that CR2 calls, perhaps not understanding that the CR2 is designed to be able to load the grouped object and textures from entirely different directories. Light "gels" and HDRI images in the same "Light" directory as the light pose file, etc.. are also common when, IMO, they shouldn't be there. The confusion is compounded by the fact that the applications, themselves, use directory structure to label the "Content Folder" displayed to the user. Though, there are some efforts that appear to be moving towards a more dynamic approach. (Both DS/Poser have some systems in place to allow for that) BUT, the demands of legacy products and backwards compatibility will dictate that the program's folder structures will be with us all for a very long time, yet.

For someone like me, who directly accesses obj and texture files, I get... annoyed when they're not in the appropriate directory. (I use the old P3DO browser to quickly read CR2 files and the like when presented with unconventional content.)

 

[Alisa]

I couldn't function like that.. For myself, I keep everything organized by the standard conventions. I'd have a heart attack if all that stuff was located in a Character folder.

hee hee - I started doing that when I got a third party addon for Poser (before Poser actually allowed you to do that), after first using DAZ Studio. Their content is arranged that way, and to me it made more sense than going back and forth between the Character folder and the Pose or Material folder (at that time, pz2 MAT poses were more in use than the mc6 material files).

Everyone has a different way of arranging their content - but we want the store version to conform to the way the program does things (to the degree we can ).

 

[Morkonan]

...Everyone has a different way of arranging their content - but we want the store version to conform to the way the program does things (to the degree we can ).

Absolutely. Imagine if DS or Poser changed something that relied on content producers having obeyed program conventions... All of sudden, Content Producer XX's product may no longer work in DS/Poser version XX, even if the ability for it to work in those new versions is possible if only they had just obeyed the original conventions.

I should run a scan on my content folders just to see how many producers have lumped texture files in the Character folder or left .mtl files for .obj in the Geometries folder... Goodness knows how many juicy HDRIs or IBLs are hidden in the Lights folder. I am sure there are probably half-a-gig worth of redundant .obj files stuffed in my Poser's Props directory... :/

 

[Alisa]

I should run a scan on my content folders just to see how many producers have lumped texture files in the Character folder or left .mtl files for .obj in the Geometries folder... Goodness knows how many juicy HDRIs or IBLs are hidden in the Lights folder. I am sure there are probably half-a-gig worth of redundant .obj files stuffed in my Poser's Props directory... :/

Ha ! I bet LOTS!

 

[Doodle Designs]

Now I'm confused about how I should be structuring my folders. I have been using the folder structure provided in the developers kit, but I'm not sure if I interpreted it correctly. To me, it made sense to have the props in the Prop folder, and then create the Materials folder as a sub-directory within the Props folder. This makes it easy and convenient for the user to find the materials options once they've loaded a prop. And they don't have to go back and hunt for the props folder again if they decide to add another prop - and then hunt back to the materials folder if they want to change the material for the added prop.

I also create sub-folders within the Props folder for Lights, Cameras, etc.

Like this for the Accessories for Him and Her product:

The props are in the Accessories for Him and Her > Props > Doodle Designs > Bathroom Accessories folder. The material options for those props are in the Materials sub-folder.

I do it this way because there's nothing I dislike more than having to go up and down the folder structures looking for the various materials, poses, lights, cameras, etc, etc, etc. for a product I have purchased. The way I do it, once the user is in the prop folder, they have access to ALL the associated folders for that product right at their fingertips. No hunting.

BTW - I looked at a few of my HiveWire purchases to see how they did it, and they were structured like this as well.

Is the way I'm doing it okay?

 

[Glitterati3D]

For example, for my OWN Poser files, I move everything into the Character folder, in sub folders that make sense to me. So I have a folder for skirts, and then a Material subfolder with all the skirt materials (well, more complicated than that, but the idea is that the mc6 files are in the Character folder.).

My runtime is arranged the same way. I always hated having to run from Characters for the clothing to poses or materials for the materials, Props for shoes, then hair, then back to poses for things like Heel poses, etc. And it was especially bad when the creator didn't follow a naming convention at all and I couldn't find the appropriate folders.

The only things I never change are the Geometries folder and the Textures folder.

 

[Alisa]

Same here, Traci.

Yes, Beth, for DAZ Studio, that's exactly how it's done.

Looking cool!

 

[Doodle Designs]

The only things I never change are the Geometries folder and the Textures folder.

Same here.

Yes, Beth, for DAZ Studio, that's exactly how it's done.

Phew! That's a relief!

I'm in the middle of reconstructing the entire product line because I realized that changing my brand name means all the file paths are wrong - they have the Doodle Dream Designs and simply renaming the folders to Doodle Designs won't work. I had to go back to square one of importing the objs, reapplying the materials, saving the assets and materials. I created a lot of extra work for myself, but a good thing that came out of it is I realized that I could improve on some of the materials. I also realized that I had forgotten to add lights for the candles.

 

[Alisa]

That often happens, doesn't it? You lose work or have to redo things and come up with something even better!

 

[Doodle Designs]

Right.

But I have to watch out for my tendency to tweak. I can go overboard on tweaking a project. Gotta wrap things up sometime!

 

[Alisa]

Yep!

 

[Faery_Light]

I found this is a problem too but started moving only the folders I wanted to zip to my main drive (C) and zipping from there, ended the problem.
Poser will give this problem too if you have everything on external drives and doing the same for them as for DS solves it.

Then when finished I move it back where I like to keep it.