-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to rip CD with extremely long title #453
Comments
Fixes #453. Signed-off-by: JoeLametta <JoeLametta@users.noreply.github.com>
Fixes #453. Signed-off-by: JoeLametta <JoeLametta@users.noreply.github.com>
Fixes #453. Signed-off-by: JoeLametta <JoeLametta@users.noreply.github.com>
@the-confessor Hi, I've just commited an untested fix in 151f6c8 (in a custom branch): could you try if that one fixes your issue? Thanks, |
I applied that patch and the result is the same - exact same stack trace. I notice that the patch is in cd.py, which doesn't appear in the stack trace. |
Update - not only does it not fix the issue, it seems to have other side effects, e.g. here is the output of another CD rip with that patch applied:
My templates:
|
Thanks for the reply. import os
def check_path_length(path):
"""
Check whether the path and its components respect the filesystem limits.
This method assumes the provided path has been normalized.
The limits retrieved aren't always reliable as some platforms
may provide deceptive values.
NOTE: os.pathconf() is only available on Unix.
:var path: normalized path
:type path: str
:returns: True if length of path and its components respect the filesystem
limits, False otherwise
:rtype: bool
"""
components = path.split(os.sep)
comp_max_len = len(max(components, key=len).encode())
fn_lim = pathconf(path.encode(), 'PC_NAME_MAX')
path_lim = pathconf(path.encode(), 'PC_PATH_MAX')
return comp_max_len <= fn_lim and len(path.encode()) <= path_lim I think that the method What's needed to do to truly address this issue is:
For example on Linux it seems that any component of the path can't be longer than 255 bytes so the function should take care of this (shrinking) for any of the components. |
This is a case that would benefit from #342. Even after truncating to filesystem limits, I don't think I would be happy with a 255 character file or directory name. Some music players may still choke on it and it may be an issue copying to a different filesystem. |
It is quite a challenging problem, and I agree #342 would at least provide a workaround. |
In addition to the filesystem limits check we could add a feature to provide users a way to set more restrictive limits which would allow shrinking the paths even more. |
I've run into a problem ripping a CD with an extremely long title.
Doing some digging I noticed an existing issue #197 - it says milestone is 1.0 but in whipper 0.9.0 there seems to already be some kind of truncate_filename method introduced. So I am wondering if that fix is in there already, but just not working in this scenario?
The error I encounter:
The text was updated successfully, but these errors were encountered: