Opened 3 years ago
Closed 3 years ago
#6076 closed defect (wontfix)
concat format doesn't allow spaces in file names
| Reported by: | MWisBest | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avformat |
| Version: | git-master | Keywords: | concat |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug:
The concat(dec) format doesn't allow spaces in file names unless the "-safe 0" argument is passed, as it deems spaces to be an "unsafe character". The problem is allowing unsafe file names (by passing the -safe 0 argument) also enables support for absolute paths, whereas "safe" file names may only be relative paths. Spaces are an everyday occurrence in file and folder names and should be allowed by default without having to enable support for absolute file paths.
How to reproduce:
% ffmpeg -f concat -i playlist.txt ... output ffmpeg version N-83049-ge71b811 (built on 2017/01/11)
Example "unsafe" playlist.txt:
file 01\ .flac file 02.flac
Change History (6)
comment:1 follow-up: ↓ 2 Changed 3 years ago by cehoyos
- Keywords concat added; concatdec removed
- Summary changed from concatdec format doesn't allow spaces in file names to concat format doesn't allow spaces in file names
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 4 Changed 3 years ago by MWisBest
Replying to cehoyos:
Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.
Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.
I agree this isn't an "accident", the behavior matches the documentation, but it doesn't make any sense. I believe it was overlooked and is a mistake.
comment:3 Changed 3 years ago by Cigaes
Spaces in file names is a very bad idea in many situations. The concat demuxer is very conservative by default; implementing fine-grained policies would be way beyond its scope, and not everybody has the same needs as you.
If you get file names from untrusted sources, you need to validate them according to your specific security requirements.
comment:4 in reply to: ↑ 2 ; follow-up: ↓ 5 Changed 3 years ago by cehoyos
Replying to MWisBest:
Replying to cehoyos:
Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.
Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.
It is not supposed to be used for patches and not for features that you want removed.
I agree this isn't an "accident", the behavior matches the documentation
That's not what I meant.
but it doesn't make any sense. I believe it was overlooked and is a mistake.
In this case, the report is of course valid but wont-fix.
comment:5 in reply to: ↑ 4 Changed 3 years ago by MWisBest
Replying to cehoyos:
Replying to MWisBest:
Replying to cehoyos:
Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.
Uh, I wasn't aware it was the user's responsibility to create patches and that this tracker is not supposed to be used. Correct me if I'm mistaken please.
It is not supposed to be used for patches and not for features that you want removed.
I agree this isn't an "accident", the behavior matches the documentation
That's not what I meant.
but it doesn't make any sense. I believe it was overlooked and is a mistake.
In this case, the report is of course valid but wont-fix.
Alright, that's fair. Thank you for the clarification.
comment:6 Changed 3 years ago by cehoyos
- Resolution set to wontfix
- Status changed from new to closed
Assuming you agree that this didn't happen by accident please send a patch (made with git format-patch) with your requested change to the development mailing list, discussing it here makes no sense.