|
Ludek
2015-10-01 11:33
developer
~0043025
Last edited: 2016-02-25 12:24
|
I am just doing some tests and I can finally reproduce the crash from 0011799
The crash is in Window's kernel32:GetShortPathNameW() function that we use for some plugins (e.g. id3lib.dll for MP3s) that have never been long path ready. The solution should be to modify all plugins to be long path capable (using the "\\?\" prefix) and not using 8.3 aliasing at all. Note that the crash appeared only for such a paths for which also the 8.3 form was longer than 260 chars
|
|
|
|
I made few additional tests and it looks like some folders on NAS can be accessed only by using LongFileName format. Option is enabled by default.
I attached picture. |
|
|
Ludek
2016-02-25 11:51
developer
~0044205
Last edited: 2016-03-31 11:00
|
It will most probably affect many plugins (input/output/tagging) so we should do it ASAP so that it can be tested enough during MM5 beta testing.
Generally it is about elimination of ExtractShortPathName and its variants entirely. And enabling scan of long paths (i.e. reverting 0011799 -- IsLongLocalFilePath conditions)
|
|
|
Ludek
2016-03-31 10:35
developer
~0044359
Last edited: 2016-03-31 11:08
|
Ticket LSM-222-18603 shown that the same crash (0012868:0043025) can appear when scanning device tracks (external HDD handled as portable device) for FLAC file with 266 chars long path, so we should ignore scanning device files with path longer than MAX_PATH until this issue is fully resolved.
Added the ignoral (fixed the crash) in build 4.1.12.1786
|
|
|
|
Separated this issue as it involved WMDM and tracked in 0013195 |
|
|
michal
2016-04-05 17:06
developer
~0044383
Last edited: 2016-04-05 17:09
|
I've made some changes and tried to make it working for parsing and playback. And paths >260 chars (and using the "\\?\" prefix) are very problematic. The main problem is, that interfaces we use for audio decoding of some main formats (from WM layer and Media Foundation, e.g. for mp3 or wma, plugins in_wmp3 and in_mfaudio) have sometimes serious problems with long paths. Some of them fail with error "The system cannot find the path specified", some crash with AV. I did not find any workaround, it seems, this way of long paths handling is not possible.
|
|
|
|
in your tests is MMW capable of accessing and reading those Files for Auto-Organize, Metadata, ....
Main complain from users is that MMW do not Import Long filename files.
Once imported we can worn them about potential risks and solution eg. Files to edit -> Long filenames [->] <FOLDERS>
|
|
|
Ludek
2016-04-06 08:26
developer
~0044390
Last edited: 2016-04-06 11:32
|
I don't see a benefit of having long filenames in library once they are causing various issues. This would raise eSupport tickets rate due to this unpredictable crashes/issues. If we are unable to make all input/format/tagging plugins and MMW to _fully_ support long filenames (which seems BTW generally impossible due to Windows limitations) then I would suggest to not scan them into library at all.
|
|
|
|
peke: symbolic links are NTFS only (so would solve issue for only part of the users) and are problematic because of this:
"The default security settings in Windows Vista/Windows 7 disallow non-elevated administrators and all non-administrators from creating symbolic links." |
|
|
|
Fixed in MM5, in build 2161. |
|
|
|
Verified 2161 and 2164
Tested filenames on up to 1024 Chars. |
|
