[goratnik]

More info would be necessary - how the limit would be applied, to the filename alone or to filename and path?

Best would be notification when starting download.

I have quite a lot of long names and I already detect and shorten them manually, but for this I need the complete name without truncations to keep the important parts even at the end of filename (variant descriptions for YouTube come to mind as a common example), so it should be a notification. I would prefer to avoid forced loss of information even before I have a chance to edit the auto-generated strings, and yet I would like to be warned that the path is still too long.

The limit itself should be configurable: even if target path would be within the limit, it is possible file would be later moved to another above the limit, so changing the limit could help as a form of prediction.

[pspzockerscene]

Originally Posted by goratnik

to the filename alone or to filename and path?

Only to the filename.
We will never touch the download path. That would be too risky.

More info:
- Limit is only applied to the filename
- Limit is only applied if a previous wirte-test to the path with the existing filename has failed [through an initial write-test, it is then clear that writing a shorter filename is possible so the issue is the long name, not a permission problem]
- Filename will be cut at the end, similar to how browsers are doing it and of course, file-extension will be preserved

Originally Posted by goratnik

Best would be notification when starting download.

That was not planned but I'll think about it.

Originally Posted by goratnik

and yet I would like to be warned that the path is still too long.

I wanted to have this as a setting either way so if turned off, JDownloader would display a message accordingly.
Maybe the best would be to have a dialog similar to "do you want to overwrite the existing file" along with a "don't ask again" dialoge.
You are free to already test this feature, see:
https://support.jdownloader.org/know...up-ide-eclipse

Real life example of a file with a name that is too long for a default Windows installation:

drive.google.com/file/d/1R8fpgJBb1OKx2ghqOQBC6KI5hvDNgGHJ/view

Even when downloading this via browser, the browser will shorten the name and there will be not notification.

Fyi:
With a lot of the filename related changes, we did orientate ourselfes on the browsers' behavior though of course there are more thigns to consider in JDownloader such as extensions of multipart archive files which we need to make sure not to break.

Originally Posted by goratnik

The limit itself should be configurable: even if target path would be within the limit, it is possible file would be later moved to another above the limit, so changing the limit could help as a form of prediction.

I'm really unsure about this as this would also mean that my current way of even detecting the limit would need to be changed but either way, it isn't finished yet so I'am open for suggestions.
I'd love to get feedback from you after actually testing it in the dev build. You do not(!) need to be a coder to be able to setup and run said version.

[goratnik]

Originally Posted by pspzockerscene

Only to the filename.
We will never touch the download path. That would be too risky.

<jd:packagename> is a part of download path and can be the reason file exceeds length limit, even if the file itself would be something like image.png - no truncation would bring it within the limit, if the total would be for example 270.

Using your own Google Drive link, do not change Package name

• set package name to

  Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.  Now we are engaged in a great civil war, testing whether that nation, or any

• set download path to something like C:\<jd:packagename>
• set file name to that simple image.png

Originally Posted by pspzockerscene

we did orientate ourselfes on the browsers' behavior

My understanding was that the goal is to extend browsers with additional control thanks to existence of LinkGrabber step, which is not present in browsers. A step that would allow selecting possible variants for download, collect additional information, build informative names according to strict scheme instead of just picking a random string thrown by the server not expecting for anyone to see it. In other words, control unimaginable for download manager built into any browser.

One of such steps would be an ability to freely choose which parts (characters) of auto-generated filename should be retained; for example, I put quite a lot of information into YouTube filenames, which I consider mandatory and usually give moderate lengths, but used tags contain also video name and channel name, which can be 100 and 50 characters long, respectively. Such long values can happen at any time, I may miss them, but the least I could expect is a space for correction without the need for redoing work of LinkGrabber to find values of missing tags, which might be not necessarily easy to access. I do have to occassionally fix filesystem, so a warning system would be welcomed by me.


Edit: to further elaborate, I don't have any problem writing excessively long paths on my Windows 10, JDownloader (and Capture One on a side note) doesn't give a squeak, files are safe and complete, that are other applications that fail due to expectation of paths fitting within 255* characters... A bit of annoying tinkering is necessary, usually moving up the folder tree is enough to resolve my cases, but I'm not in despair over long names enough to kill them instantly, I just see this feature as a chance for a soft warning.

Without peeking into trial implementations, path length limit is predictable and can be calculated in advance, so the way I see this would be similar to Duplicate links:

• When LinkGrabber sees that a download would exceed path length limit, adds it to a "Too long download paths" custom view and highlights these entries.
• After clicking "Add to download" there would be a popup "You are trying to add links that would result in too long file paths. Please choose how to continue:" with options like "Truncate", "Do not add links with too long download paths", "Burn the world Keep as-is"

Edit2: can we split the discussion, please? This is no longer about illegal characters, but paths that are not even illegal, just undesirable.


Edit3: I have checked in Powershell and I have a message here that could be translated to "length of fully qualified file name has to be lower than 260 characters, while length of folder name lower than 248 characters".

[Jiaz]

Originally Posted by goratnik

path length limit is predictable and can be calculated in advance, so the way I see this would be similar to Duplicate links:

No it's not, because it's determined by OS+OS Settings (windows can be enabled(maybe newer have default enabled) to support larger path elements) + underlying/used Filesystem.
There are still ppl using Fat32. You download from linux to windows network share and so have to deal with filename limitation of different OS than JDownloader is running on. Also a question of portability as you can download the files on linux and maybe want to move them later to windows filesystem and may fail because file/path names are too long

so maybe the max file/path length should be a config like AUTO, custom, Predefined values...

Originally Posted by goratnik

Edit2: can we split the discussion, please? This is no longer about illegal characters, but paths that are not even illegal, just undesirable.

Sure! Feel free to open new thread about this topic and continue conversation over there

[goratnik]

Originally Posted by Jiaz

No it's not, because it's determined by OS+OS Settings (windows can be enabled(maybe newer have default enabled) to support larger path elements) + underlying/used Filesystem.

And I think all of that can be queried and cached, so that path OK for one location would be marked as too long in another. These powershell commands had to get their info from somewhere. At least as long as weird mounts are not in use... and even then the best option would be to fail instead of silently breaking the originally planned naming.

Originally Posted by Jiaz

There are still ppl using Fat32.

Can we consider FAT16 as well?

Originally Posted by Jiaz

You download from linux to windows network share and so have to deal with filename limitation of different OS than JDownloader is running on. Also a question of portability as you can download the files on linux and maybe want to move them later to windows filesystem and may fail because file/path names are too long

That's indeed why I mentioned making this configurable, to not only have the limit itself, but also possibly lower.

Originally Posted by Jiaz

Sure! Feel free to open new thread about this topic and continue conversation over there

[Jiaz]

Originally Posted by goratnik

Can we consider FAT16 as well?

Reads as you're mocking me but I'm dead serious, we still have ppl with that old filesystem in use. Of course I would not respect those few users for major decisions but just wanted to point out that different filesystems have different filelength. eg

eCryptfs can only store filenames of up to 143 characters when filename encryption is enabled

[pspzockerscene]

Originally Posted by goratnik

<jd:packagename> is a part of download path and can be the reason file exceeds length limit, even if the file itself would be something like image.png - no truncation would bring it within the limit, if the total would be for example 270.

I know but please understand that for now, this is only about "too long filenames", not about other parts of the path.
We can talk about this once the first change is done but a change which can possibly alter users set paths is definitely not planned!

Adding to this:
Using the already existing features of JDownloader, you can already alter parts of the path and also put a length limitation in place.

Just a theoretical note here:
If this was about the path and filename, it would make this significantly more complex.
Here is my rough plans for now:

1. Add proper detection of the different error cases such as "path too long", "filename too long", "permission issue" so that instead of just "invalid download path", JDownloader will finally display more meaningful errormessages on failures due to path issues. This is already 50% of my personal goal here.
2. Add filename auto shortening feature.

Originally Posted by goratnik

My understanding was that the goal is to extend browsers with additional control thanks to existence of LinkGrabber step, which is not present in browsers. A step that would allow selecting possible variants for download, collect additional information, build informative names according to strict scheme instead of just picking a random string thrown by the server not expecting for anyone to see it. In other words, control unimaginable for download manager built into any browser.

You misunderstood my point, orientating myself on something doesn't mean that I'd be planning to just copy the browsers' behavior here, I just don't need to reinvent the wheel unnecessarily.
I thought it was clear that JDownloader is s different tool with different use cases.
For example nowdays most of all users will typically use one default download path for browser based downloads. In JDownloader however, this is obviously different.
This means that for browsers it is significantly easier to shorten filenames than it will be for JDownloader.

Originally Posted by goratnik

One of such steps would be an ability to freely choose which parts (characters) of auto-generated filename should be retained; for example, I put quite a lot of information into YouTube filenames, which I consider mandatory and usually give moderate lengths, but used tags contain also video name and channel name, which can be 100 and 50 characters long, respectively. Such long values can happen at any time, I may miss them, but the least I could expect is a space for correction without the need for redoing work of LinkGrabber to find values of missing tags, which might be not necessarily easy to access. I do have to occassionally fix filesystem, so a warning system would be welcomed by me.

Again: At this moment it is planned to simply shorten the filename.
Your rough idea though is not too bad.
Similar to the "remove bad chars rpleace map", I can imagine adding a "shorten filename replace map" which will be appended first and after this, auto truncating can be applied if needed.
Prividing the ability to define characters/patterns which can be removed from "too long" filenames sounds like a smart move to me.

Originally Posted by goratnik

Without peeking into trial implementations, path length limit is predictable and can be calculated in advance, so the way I see this would be similar to Duplicate links:

No it is not predictable, see Jiaz' reply.

Originally Posted by goratnik

And I think all of that can be queried and cached, so that path OK for one location would be marked as too long in another. These powershell commands had to get their info from somewhere. At least as long as weird mounts are not in use... and even then the best option would be to fail instead of silently breaking the originally planned naming.

No need to add such extensive caching. You also need to keep in mind that when writing files, virtually anything can happen at any time such as:

• Disk full (remember, other applications can also write data to it)
• USB drive was removed during download
• Network drive goes down during download
• Mounted drive got unmounted
• And more

At this moment it is kind of "trial and error" with a small amount of caching.

Originally Posted by goratnik

Can we consider FAT16 as well?

While this might be ment as a joke, one of the hidden features of JDownloader is its vast compatibility, even to older systems.

Originally Posted by goratnik

That's indeed why I mentioned making this configurable, to not only have the limit itself, but also possibly lower.

My recommendation hasn't changed: Please get the dev build running and test our changes so we're not only talking about theoretical stuff here.
A quick sidenote: If you have removed the Windows path limit for your system, you will never have to deal with this problem either way.
We've also mentioned this here:
https://support.jdownloader.org/know...load-directory

Originally Posted by goratnik

I prefer letters over smileys so what does this mean?
If you want, you can open a new thread and just in case you ment to say this:
Sure I can also move parts of existing threads into a new thread.

To me, using this thread is fine.
Interested users will eventually find it via Google even though the title implies that it is about another topic.
I could also just update the title.