Topic: rename truncation change is really bad - please put it back the way it was (Read 6547 times)

rjm · « **on:** February 24, 2012, 10:15:53 pm »

I've been offline for a month tending to a sick mother in hospital. I'm back now tagging with 17.0.92 and need to voice a strong concern about changes that have been made to the "Rename, Move, & Copy" function.

It is truncating filenames that do not need to be truncated. For example:

F:\$Media\Course\Video\Special Interest\Cooking\Harumi Kurihara\Your Japanese Kitchen\Wakame Udon and Kikka Vegetables (Seaweed with Noodles Soup and Pickled Vegetables Cut Like Chrysanthemums).avi

Is being truncated to:

F:\$Media\Course\Video\Special Interest\Cooking\Harumi Kurihara\Your Japanese Kitchen\Wakame Udon and Kikka Vegetables (Seaweed with Noodles Soup .avi

The length of this filename is way below the limit set by Windows.

I know you made the change to address some problem however I have used the rename function almost everyday for many years and never ran into whatever problem you fixed.

MC must permit folder\filenames to use the maximum length allowed by Windows.

Please put it back the way it was, or give us a legacy option if we don't care about whatever problem was addressed.

rjm · « **Reply #1 on:** February 24, 2012, 10:26:30 pm »

Woaa...

I just tried a work around by moving and renaming the files into the root directory to minimize the path length (on the assumption I would move them without renaming them as a 2nd step).

MC is still truncating the file names to something like 64 characters (despite the null length path).

This is really really bad. I am basically shut down until this is fixed.

rjm · « **Reply #2 on:** February 25, 2012, 12:19:01 am »

It gets worse...

Now I've got a short file name (5 characters) and a reasonably long path (but still well within the Windows limit) and MC is truncating the path to about 64 characters.

Does MC come with an extended warranty for monitors?, because I'm about ready to smash mine.

JimH · « **Reply #3 on:** February 25, 2012, 06:04:02 am »

The problem is that, if you add up all the formerly allowed lengths, they could occasionally exceed what Windows itself supports, so MC could create files that couldn't be moved or deleted. Apparently Explorer also allows this, but that is a bug.

So please find a way to live with it.

darichman · « **Reply #4 on:** February 25, 2012, 06:52:00 am »

I am definitely with RJM here. I am constantly manually changing the filenames MC has truncated and this is having a real toll on my workflow.

I understand the logic behind limiting to the windows length restriction so as not to create files that windows itself can't handle, but I do not understand the execution.

From MSDN:
"Individual components of a filename (i.e. each subdirectory along the path, and the final filename) are limited to 255 characters, and the total path length is limited to approximately 32,000 characters."

So it's the individual elements in a file path (ie C:\__A__\__B__\__c__.* ) that the windows limit applies to, not the total file path length itself?
If this is the case, why is MC so restrictive? (ie in many cases will restrict a single field to 60?)

Quote from: darichman on December 17, 2011, 09:06:42 pm

MC will no longer let me have filename/paths like:
  O:\Film\Dr. Strangelove or, How I Learned to Stop Worrying and Love the Bomb (1964)
   O:\Film\[Movie] ([Year])
  O:\Music\Soundtrack\50 First Dates, Love Songs from the Original Motion Picture Soundtrack
   O:\Music\Soundtrack\[Album]

The examples above are very simple and common examples of where MC will unnecessarily truncate the filepaths
  - No individual path elements break the windows length limit
  - Only one or two fields are used in each of the above examples, why limit them to 60 characters?
  - The paths cause no problem in windows.

And while this is meant to be avoiding a problem as Jim points out, it also introduces new ones too...

Consider numbered series (Part 1, Part 2) etc ... where the differentiator is at the end of the field string
[A Field] = _____ Part 1
[A Field] = _____ Part 2

If these fields are used in the

filename, the two files will end up with identical filenames as the "part 1" part has been truncated, and it will be left to windows to append (1), (2) to the files randomly, confusion abounds
folder element of the file path, then paths which would have been different will now be the same (as the "part 1" etc part has been truncated), and files would unexpectedly end up in the same folder. Coverart gets rewritten etc etc. And worst of all, the user is told nothing of this

rjm · « **Reply #5 on:** February 25, 2012, 12:17:36 pm »

Quote from: JimH on February 25, 2012, 06:04:02 am

The problem is that, if you add up all the formerly allowed lengths, they could occasionally exceed what Windows itself supports, so MC could create files that couldn't be moved or deleted. Apparently Explorer also allows this, but that is a bug.

So please find a way to live with it.

I have used the rename function for 8 years on 270,000+ files. I am aware of the potential problem. I think I first reported it about 3-5 years ago when MC frequently exceeded the Windows max path length. It was a pain. You then made a change to the path length algorithm that prevented the problem for 99.99% of cases. You have now fixed the remaining 0.01% of cases at the expense of making MC unusable for me.

As per darichman, the maximum rename length of fields has been reduced from the 255 characters allowed by Windows to 60 characters. This is not a tweak. This is a huge change with profound implications for library designs and workflows. And is far more restrictive than Windows requires. In my case, I frequently exceed 60 characters in fields that I use for renaming like [Album] and [Name].

After much experimentation I have determined that the problem was introduced in 17.0.51:

Quote

5. Fixed: Some CD rips, especially classical, were generating folder names that were too long for the system to handle.

I have downgraded to 17.0.50 and rename is working as required again.

KingSparta · « **Reply #6 on:** February 25, 2012, 12:34:20 pm »

Not that it will make a difference, I am with you to rjm.

I do think people who have classical music it will effect them more.

MrHaugen · « **Reply #7 on:** February 25, 2012, 12:41:34 pm »

Why only 60 characters? It seems very strange of windows allows for 255? I'm also concerned about this. I have some files with long file names. I use Track number, Album, Artist and Name for my music, so there is probably lots of them that will be affected if I use this tool.

rjm · « **Reply #8 on:** February 25, 2012, 12:46:40 pm »

Quote from: KingSparta on February 25, 2012, 12:34:20 pm

I do think people who have classical music it will effect them more.

And apparently collectors of non-fiction like myself where [Album] and [Name] can be quite long.

KingSparta · « **Reply #9 on:** February 25, 2012, 01:01:46 pm »

I think 125 chrs would be a better number to go for, if we could not have 255 chrs.

didn't CDs have a limit one time of 64 chrs?

rick.ca · « **Reply #10 on:** February 25, 2012, 02:53:05 pm »

The justification for the change was stated to be...

Quote from: JohnT on December 15, 2011, 11:09:17 am

The reason we use a fixed value for the path portion is otherwise we could end up putting tracks from the same album into different folders because they might get truncated differently depending on the name portion of the complete filename.

The logic is inconsistent. This particular possibility is recognized as something that must be fixed in an arbitrary manner, while the truncation itself is assumed not to affect the user in other unpredictable ways (they won't even be notified of).

The tool produces a preview, so it's perfectly capable of detecting any error conditions before it executes. Recognizing unexpected results can occur if any files are excluded from the rename, or the rename arbitrarily changed to avoid the error, the logical thing to do would be to refuse to execute the rename until the error conditions are eliminated. An error message could be displayed, and the errors highlighted in the preview. That would bring the issue to the user's attention, allowing them to make an appropriate correction...

Change the file pathname pattern;
Introduce an expression to reduce the length of offending string in an appropriate manner (e.g., by removing characters from the middle, rather than significant ones at the beginning or end); or
Shorten the data (the most straightforward solution if the problem is rare).

KingSparta · « **Reply #11 on:** February 25, 2012, 06:31:49 pm »

i found it

Joliet (file system)

The specification only allows filenames to be up to 64 Unicode characters in length. However, filenames up to 103 characters in length do not appear to cause any problems.

MrHaugen · « **Reply #12 on:** February 26, 2012, 07:48:45 am »

In that case, should it not be enough to truncate long file names when burning to CD's?

KingSparta · « **Reply #13 on:** February 26, 2012, 08:33:27 am »

I don't think they use the Joliet (file system) anymore

Hendrik · « **Reply #14 on:** February 26, 2012, 08:57:53 am »

I don't think anything ever replaced Joliet, although i guess data CDs are going out of style as a whole.

rick.ca · « **Reply #15 on:** February 26, 2012, 02:43:44 pm »

Joliet applies only to CD's, but it doesn't make sense to be arbitrarily truncating pathnames in that case either. Why attempt to correct an error condition in a way that will likely introduce another error—and not notify the user?

rjm · « **Reply #16 on:** February 26, 2012, 03:37:17 pm »

Gotta say I am worried here.

I fear that I belong to a small minority of (non-fiction) collectors that require long tags.

And I fear that I belong to another small minority of users that care about a non-truncated mapping between tags and filenames.

And I fear that JRiver has decided to not revisit this decision because most customers are not concerned.

Perhaps all I can do is appeal to the integrity and goodwill of JRiver.

JRiver has done an amazing job over the last 8 years of maintaining backward compatibility.

Please continue this tradition by not changing something as fundamental as the rules regarding media file naming.

If it helps, I would be more than satisfied with a registry enabled legacy option that made me responsible for any problems I create by exceeding Windows limits.

And I am patient and can happily work with 17.0.50 for weeks or months until you have time to address this.

Thanks for your consideration.

bspachman · « **Reply #17 on:** February 26, 2012, 03:58:26 pm »

I remember files that were handed off to QuickTime for handling needing to be limited to a 60 character filename. My renaming expression has logic in it for exactly this case.

Other than that specific instance, you can count me in the 'allow long tags' camp....

brad

Scolex · « **Reply #18 on:** February 26, 2012, 05:37:55 pm »

I will agree that it doesn't really make since to truncate a file name on the basis that I don't think it would be very difficult to just check the number of characters in the full path, but I am not a programmer so I could be wrong. The full path referenced in the first post is no where near the 255 character limit.

On the other hand there is a post above stating that the number of characters allowed in a full path is 32,000, this is not true for all Windows versions as I just tested on an XP machine by creating a new folder, renamed it entering random characters until it stopped taking them and tried to create a txt file in that folder which gave me an invalid path error so there is a need for some limit. I actually didn't even make it to 255 in the folder name (241) due to the length of the path to the parent folder.

glynor · « **Reply #19 on:** February 27, 2012, 06:12:29 pm »

Quote from: rjm on February 26, 2012, 03:37:17 pm

I fear that I belong to a small minority of (non-fiction) collectors that require long tags.

I don't know if that's true.

I have plenty of long tags. I just do not care even a little tiny bit if they are truncated in the filesystem. I never look at them in the filesystem other than to do weird maintenance tasks, and even then, frankly, I use MC to "drive" it.

MC is the canonical view, not Windows Explorer, to me. And that's why I don't care. As long as MC's Library is there (and I am sure to back it up) then I don't care what the filesystem calls the files, within reason. If catastrophe happens, that's what the in-file tags are for.

When I'm doing that file maintenance... I don't know, I'd have to come up with some pretty contrived instances where it impacts me. I agree that the current solution isn't that elegant, but... I just don't care.

Alex B · « **Reply #20 on:** February 27, 2012, 06:30:15 pm »

Quote from: Scolex on February 26, 2012, 05:37:55 pm

On the other hand there is a post above stating that the number of characters allowed in a full path is 32,000, this is not true for all Windows versions as I just tested on an XP machine by creating a new folder, renamed it entering random characters until it stopped taking them and tried to create a txt file in that folder which gave me an invalid path error so there is a need for some limit. I actually didn't even make it to 255 in the folder name (241) due to the length of the path to the parent folder.

In addition Windows XP Explorer provides lousy protection.

It was easy to trick it to create an inaccessible file just by replacing a short folder name with a long name. I have now this file: F:\_I actually didn't even make it to 255 in the folder name (241) due to the length of the path to the parent folder\I actually didn't even make it to 255 in the folder name (241) due to the length of the path to the parent folder\I actually didn't even make it to 255 in the folder name (241) due to the length of the path to the parent folder.txt

rick.ca · « **Reply #21 on:** February 27, 2012, 06:40:20 pm »

Quote from: glynor on February 27, 2012, 06:12:29 pm

I just don't care.

It's not unusual for a user or other applications to need to interact with the files in some way, which may require the files be saved in logical and consistent manner. Also, the truncation of folder names which have the significant part at the end will result in errors.

Would you care if the program just refused to do anything if the resulting filenames were illegal? You could always use your own rules to ensure that couldn't happen.

glynor · « **Reply #22 on:** February 27, 2012, 08:13:05 pm »

Quote from: rick.ca on February 27, 2012, 06:40:20 pm

Would you care if the program just refused to do anything if the resulting filenames were illegal?

I don't know that I'd like that, but... Like I said, I don't think the current solution is necessarily elegant. There are probably lots of possible solutions.

I was only commenting because rjm seemed to think that the lack of outrage meant that he was relatively alone in his need. I was saying... No, I use long tags too. This is why it doesn't much matter to me, and why I'm not getting my torch and pitchfork.

Others probably share this opinion, or... Have never hit the limits in a meaningful way.

rjm · « **Reply #23 on:** February 27, 2012, 08:29:32 pm »

I know I am in the minority. That's why I am worried.

I am not making the case that I am right and others are wrong. It's a matter of personal preference.

I desire to be consistent with 8 years and 270,000 files of previous work. And my design is based on taking full advantage of limits imposed by Windows. Limits which MC prior to 17.0.51 also took full advantage of.

rjm · « **Reply #24 on:** February 27, 2012, 08:40:34 pm »

Quote from: Alex B on February 27, 2012, 06:30:15 pm

In addition Windows XP Explorer provides lousy protection.

It was easy to trick it to create an inaccessible file just by replacing a short folder name with a long name.

Yes. It's also quite easy to recover from this error once you understand what is going on. Temporarily rename a long path to a short path, move the file up, restore the renamed path, and then rethink where and how to name the offending file.

Matt · « **Reply #25 on:** February 29, 2012, 10:32:06 am »

We've updated the truncation for a coming build.

It uses this logic:

if (path > 230)
{
shorten folder names, starting at the tail, leaving at least 20 characters per folder name
}

if (total > 260)
{
shorten name
}

Shortened components get a ... at the end.

To ensure there's space for the filename to be made unique (ie. (1), (2) added to it), some of the limits above can vary by a few characters.

rjm · « **Reply #26 on:** February 29, 2012, 11:28:07 am »

Excellent!

The demands on your time from so many smart users with so many good suggestions must be overwhelming.

Sincere thanks for caring about an issue that might not increase your sales.

vagskal · « **Reply #27 on:** February 29, 2012, 12:26:32 pm »

I think you should move this tread to the public board now. It shows how you, at least in the end, always care about your loyal users.

I am happy for you rjm. You had a good case.

(You may of course delete or edit this post if you wish before moving the thread should you decide to do so.)

darichman · « **Reply #28 on:** March 01, 2012, 04:05:51 am »

Thank you so much!! On a personal level, thank you to Matt and J River for compromising here - this will make a big difference to how I personally will use MC... and at a broader level I think this says volumes about the level of support, interaction and response to consumer interest from the developers.

KingSparta · « **Reply #29 on:** March 01, 2012, 05:46:13 pm »

Thanks Matt, JimH

INTERACT FORUM

Author Topic: rename truncation change is really bad - please put it back the way it was (Read 6547 times)