[pspzockerscene]

Originally Posted by EquiNox

Ok, thanks, I thought it was hard-wired in the file system although 260 characters total lenght seems to be ridiculous to me nowadays.

My guess is that the limit will be removed by default with the next major Windows version (maybe Win 11) though maybe it is still there for good reasons.
I haven't tried removing it as I was afraid of issues it could cause and I'm usually not running into the "too long path" issue.

Originally Posted by EquiNox

I guess I should switch to Linux, that probably does not have such silly limitations.

Exactly.

Originally Posted by EquiNox

However it's still not working correctly, JD still returns "Invalid download directory" for the very long file names.

Any examples for that?
Does your filename maybe additionally contain unsupported characters?

Originally Posted by EquiNox

I fully understand your objections and it's not my intention to clutter or slow down the plugin with too many options.

It's not for these reasons.
I just think it doesn't make sense to create plugin settings for stuff that should be solved by a global feature otherwise you could e.g. add the "crop filename" feature hundrets of times for each plugin -> Makes no sense.
Same for custom filenames because our Packagizer feature can be used to do pretty much the same you can do inside the flickr.com plugin at this moment but for some reason custom filenames have been added as a plugin setting back then which is why I kept it... users hate it when existing features get removed and I can fully understand this

Originally Posted by EquiNox

...it would cut off the username and the content_id probably, so I don't anymore know where the file was from.

As described in our Packagizer article, you can also use plugin specific tags inside filenames.
In this case, all tags given in the flickr.com plugin settings are 1:1 the tags you can use in Packagizer.
... so let's pretend that the title is always the problem meaning that "username_url" and "content_id" will always be missing 100% if a filename gets cropped... so we'll just add this info to the new name:

<jd:orgfilename:1>_<jd:prop:username_url>_<jd:prop:content_id>.<jd:orgfiletype>

Originally Posted by EquiNox

...it does work, however there is no guarantee that the title is always cut off at the same position, when for example I want to change username_internal to the new pathalias a user now has, then the length of the prefix before the title can change so the title will be cut off differently.

Sure the name will be cut off differently because it is a different name.
To be honest I wouldn't know how to solve this other than adding a logic to cut off clean after specified tags and still allow different lengths.

Originally Posted by EquiNox

Maybe a packagizer-rule can be defined that does only limit the length of the title, but leaves the rest of the filename untouched? I am not to much a regular expressions expert, but I know you can do some magic with that.

That's not possible using only Packagizer rules because:
- Packagizer cannot do String operations (e.g. modify strings, crop strings or do uppercase/lowercase conversions)
- Apart from the defaults needed to create rules, Packagizer cannot do things like "if <jd:prop:username_url> contains 'xxxYYY' then do ..."

You'd have to use an EventScripter script for that.
You can get help creating such scripts in this thread.
With such a script you'd definitely be able to optimize the naming scheme along with obeying your OS' limits up to "perfection".
Using a script, you'd probably simply crop the title and then build your new filename.

-psp-