"Destination path too long" issues
Apr 5, 2008 at 8:32 PM Thread Starter Post #1 of 9

Monster_Omelette

100+ Head-Fier
Joined
Sep 6, 2007
Posts
117
Likes
11
I recently purchased a larger HD for all of my music and was transferring my collection to this particular drive from a smaller external one. While this is not the first time I have encountered this problem, the "destination path too long" error is causing me considerable grief this time around. I use dBpoweramp to rip CDs into flac. While its tagging is quite competent, it often creates files with too long a name, and thus, transferring music from one hard drive to another becomes an extremely laborious and inefficient process as I must manually find and rename the files. In this case, I'd rather not have to do that with 869 of them
mad.gif


My two questions are: 1) Is there any workaround to the file name limit in windows and 2) Is there a way in dBpoweramp to shorten the file name without shortening the tags itself?

Thanks.
 
Apr 6, 2008 at 9:55 PM Post #3 of 9
This shouldn't happen randomly.

For example, if you're copying from d:\folder to e:\babuchka\more\yet\another\folder or something, that could be the problem. In that case, a simple workaround would be to put those file somewhere else (and maybe put a link in your long path instead).

There may be a real workaround but it probably wouldn't be very portable. By the way, this is a filesystem issue rather than an OS issue in principle.

In any case, you should ask the dbpoweramp people because their software shouldn't be doing something crazy enough to cause you problems to begin with.
 
Apr 6, 2008 at 11:53 PM Post #4 of 9
There is a workaround to the file name length limit in Windows. I can't remember what it is, but I'm sure if you dig around you can find it.
 
Apr 8, 2008 at 6:32 AM Post #5 of 9
Quote:

Originally Posted by HFat /img/forum/go_quote.gif
This shouldn't happen randomly.

For example, if you're copying from d:\folder to e:\babuchka\more\yet\another\folder or something, that could be the problem. In that case, a simple workaround would be to put those file somewhere else (and maybe put a link in your long path instead).

There may be a real workaround but it probably wouldn't be very portable. By the way, this is a filesystem issue rather than an OS issue in principle.

In any case, you should ask the dbpoweramp people because their software shouldn't be doing something crazy enough to cause you problems to begin with.



Moving a couple of the folders to another on the other hard drive with less sub-folders did indeed do the trick, but I have no idea how everything will react once I move all the other files onto it.

It doesn't help that all of these offending files are from my classical music tracks which make up the vast majority of my library, perhaps the dBpoweramp ppl didn't anticipate a problem with super long tags on their files. What's strange though is that Windows is already cutting off the tags of the file names, and yet I'm still running into this problem.

I'll try looking for the file name length workaround tomorrow I guess.
 
Apr 8, 2008 at 2:08 PM Post #6 of 9
I have the same problem--when a classical movement is tagged with the complete info, the file name ends up insanely long. And the only solution I've come up with is the same as yours--to move the music into folders with shorter path from the root directory.
 
Feb 27, 2009 at 3:23 PM Post #7 of 9
Quote:

Originally Posted by Monster_Omelette /img/forum/go_quote.gif
My two questions are: 1) Is there any workaround to the file name limit in windows and 2) Is there a way in dBpoweramp to shorten the file name without shortening the tags itself?

Thanks.



The tags are stored inside the files themselves as metadata, so changing the filename will not affect the tags. However, dBpoweramp uses the same data that's going into the tags to construct the filename. (Something like artist\album\tracknum-trackname.flac). The simplest thing to do would be to shorten or remove one of these components. If you look at the dynamic file-naming settings, there is a function called GRAB that can take a substring of some part of your filename. If it's not obvious how this works, you can post your dynamic file-naming string here, and I or someone else should be able to help you. dBpoweramp also has its own fairly active forum.
 
Feb 27, 2009 at 4:07 PM Post #8 of 9
Formatting the external drive as NTFS (assuming you're running Windows) instead of FAT32 will avoid filename limitations of FAT32. But using NTFS on a USB drive that gets plugged in and out can have its own issues. You need to be careful to always use the "Safely remove hardware" tool to safely shut down the drive before unplugging it. An NTFS drive can get messed up if you unplug it suddenly.

Another option is to use a tagging utility to shorten the filenames. MP3Tag and J. River Media Center (or J. River Media Jukebox) can rename files based on tags. Both programs have scripting functions that you can use to trim filenames, do if then logic, and other fancy things.

This is the filename rule I use in J. River Media Center to rename files from tags:
Mid([Album Artist (auto)],0,20)-Mid([Album],0,20)-If(IsEmpty([Disc #],1),,PadNumber([Disc #],2))-PadNumber([Track #],2)-Mid([Name],0,20)

It trims the artist, album, and track name fields to a maximum of 20 characters each. That keeps me from getting massively long filenames. Especially helpful on classical music albums.

MP3Tag has similar functions.
 
Feb 27, 2009 at 5:45 PM Post #9 of 9
Even the NTFS file system has a filename limit of 255 characters. For some reason that I don't know I have found that anything over 253 characters may cause problems. Are you moving the files themselves, or folders and sub-folders as well? Windows will then include the directory tree as part of the 255 character limit if so. Spaces count as characters in filenames.
Windows uses filenames to organize the files on your computer and to allow you to recognize them. It's completely separate from the metadata in your tags.

Since you already use dBpoweramp, I would go with rederanged's suggestion and eliminate some of the values in your filename string settings prior to ripping.
 

Users who are viewing this thread

Back
Top