Long filename support in Picard on Windows 10

[hiccup]

I am running into some brick wall trying to control the allowed character length of filenames that Picard can write.
Even when allowing lengthy file names (to an extend) by means of a file naming script, at saving them such long filenames get truncated.

Maybe it is Windows 10 interfering here, but I do have it set to enable long file paths.

Could it be that Picard has it’s own build-in restriction for the length of filenames it will write?
Or does Picard perhaps not check to see if Windows 10 is set to enable long file paths?

(I am using Picard portable)

[wlhlm]

Here is a previous discussion that may shed some light on the state of long file name support in Picard on Windows:

Picard doesn't recognize some non-Latin characters?

Starting with Windows 10 version 1607 that limitation is mostly gone.

[hiccup]

@wlhlm

Here is a previous discussion that may shed some light on the state of long file name support in Picard on Windows:

Thanks for the links. It looks like this will remain an issue for a while then.

.

Picard doesn't recognize some non-Latin characters?

Normal users will not know to add a registry switch. The average user doesn’t even realise there is a limit in the OS. Otherwise they wouldn’t try and make such insanely long folder names. IMHO there are more important issues to spend time on in Picard. Allowing people to create insanely long paths will just catch the User out when the files are used elsewhere.

“Allowing people to create insanely long paths will just catch the User out when the files are used elsewhere.”

.
This is not about trying to create extremely long filenames that exceed 260 characters. It is about filenames getting truncated to very short filenames when the files you are processing with Picard are in a deeper folder structure.
That can easily happen with e.g. classical albums that sometimes have very long album titles or artist listings, or with box sets that have deeper folder structures.
Or when just having an elaborate folder structure on your PC and the files you want to process happen to be in a deep level.

I never tried using Picard’s file rename feature before, but this is probably going to be a deal breaker for me.
(it took me a day to figure out why my $truncate script wasn’t working as expected)

[outsidecontext]

@hiccup

This is not about trying to create extremely long filenames that exceed 260 characters. It is about filenames getting truncated to very short filenames when the files you are processing with Picard are in a deeper folder structure.

Actually this is what IvanDobsky was referring to. Windows has hsitorically a path limit of 260 characters. This is for the full path, including the drive ("C:") and also including a terminating null character. This was a strict limitation of the Windows API, the NTFS filesystem has no problem supporting longer paths. Over the years Microsoft has attempted to lift this restriction, but they had been limited by the need to stay backward compatible. It is for some time now already possible to access longer paths with specially constructed path names, but that was badly supported. E.g. Windows Explorer did not allow you to create such paths, meaning e.g. you could not rename such files. With Windows 10 there is some hope now that the situation will get good finally, but it is not 100% there yet. There are still some quirks. But I think with this we can finally look at getting Picard to support such paths. We have a ticket for that.

Having said this, I looked at it earlier this year but for now I have personally given up on it. There are too much specialities and quirks around this, making this quite a time intensive thing to fully implement and test. But I would be very happy if someone would look into this.

[hiccup]

@outsidecontext

There are too much specialities and quirks around this

After some more testing, I believe you are right not to put much (any) more effort into this.

Even with long filepaths enabled in W10, even Windows itself keeps having problems with them.
E.g. when a filename already exceeds the path length limit, it is impossible to rename it in Windows itself.

It’s probably very sensible to wait making any changes to Picard until Microsoft fixes this.
But that might take a while.
They probably lack the required talent and the financial resources.

[mfmeulenbelt]

I can’t believe this is still an issue in the 21st century.

[hiccup]

I am sure Microsoft would have solved it in the 20th century if they saw a way to monetize Windows using long file paths without any issues.

[outsidecontext]

@hiccup

It’s probably very sensible to wait making any changes to Picard until Microsoft fixes this.
But that might take a while.

We have been waiting for a long time already Actually I think it would be time to start supporting this at least as good as possible in Picard, even if there are still some quirks. But yes, I think MS has good reason why they put this behind a registry flag and disabled it by default. Just for me personal I currently rather put my time into different areas. I have written down some thoughts on how to support this in Picad in PICARD-2076