View Issue Details

IDProjectCategoryView StatusLast Update
0012868MediaMonkey 5FileMonitor / Find Missingpublic2022-06-28 14:32
ReporterLudek Assigned To 
PriorityurgentSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version5.0 
Summary0012868: Ability to support long filepaths (> 260 chars) on Windows
DescriptionMost Windows applications don't support file paths longer than MAX_PATH (260 chars).

We tried to partially support them in the past (issue 0008020), but it resulted in some regressions (0010692 and 0011799)

There are two ways in Windows how to support long paths:

A) We could use "\\?\" prefix, but it varies on file system used (NTFS, FAT, FlexRAIDFS, ...), many but not all file I/O APIs support "\\?\"; you need look at the reference topic for each API to be sure

B) 8.3 aliasing, but not all file systems follow the tilde substitution convention, and systems can be configured to disable 8.3 alias generation even if they normally support it. In addition for paths when 8.3 form is still longer than 260 chars it won't work anyway.

Note that we tried to use solution A in the past which resulted in crash on some systems (0010692, 0011799).
Solution A still seems to be better, but if we want to support this again we need to resolve the crash at first (0012868:0043025), and then prepare all parts of MM code to handle long filenames (which wasn't the case previously in 0008020)
Additional Informationhttp://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
JVV-288-59986
PPU-263-30137
TagsNo tags attached.
Fixed in build2161

Relationships

parent of 0011799 closedLudek MediaMonkey 4 Scanning: Full filename and path larger than 260 chars can result in MMW crash 
parent of 0013195 closedLudek MediaMonkey 4 WMDM: Removable Storages with Long file paths >260 characters can crash/freeze MMW 
has duplicate 0012488 closedLudek MediaMonkey 4 LongFilenames: NFS/NTFS/SMB 3.0 Long Filenames support up to 32k path 
related to 0015476 closedmichal MediaMonkey 5 Application can throw EPathTooLongException, when path long enough contains unicode characters 
related to 0015572 closedmichal MediaMonkey 5 Possible EPathTooLongException when ripping CDs 
related to 0015666 closedmichal MediaMonkey 5 Tagging FLACs in long paths sometimes fails 
related to 0016334 closedpeke MediaMonkey 5 Long Path over >255 chars 
related to 0017726 closedmichal MediaMonkey 5 Files with Path >300 Chars fail to play and read Album art when browsed with MM 
related to 0018122 closedLudek MediaMonkey 5 Long Paths fail in Auto-Organize Files 
child of 0008020 closedmichal MediaMonkey 4 f_video: MM is not importing/playing some MOV Files 
child of 0010692 closedLudek MediaMonkey 4 MM 4.1 creates 8.3 filenames while tagging when running in VM on Max OS (regression in 4.1) 

Activities

Ludek

2015-10-01 11:33

developer   ~0043025

Last edited: 2016-02-25 12:24

View 6 revisions

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

peke

2015-10-03 00:04

developer  

NAS Shared folder issue.jpg (106,017 bytes)   
NAS Shared folder issue.jpg (106,017 bytes)   

peke

2015-10-03 00:07

developer   ~0043053

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

View 5 revisions

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

View 3 revisions

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

peke

2016-03-31 11:08

developer   ~0044362

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

View 4 revisions

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.

peke

2016-04-05 22:16

developer   ~0044386

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

View 5 revisions

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.

michal

2016-04-06 11:36

developer   ~0044396

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."

michal

2019-02-19 11:43

developer   ~0052691

Fixed in MM5, in build 2161.

peke

2019-03-01 02:42

developer   ~0052827

Verified 2161 and 2164

Tested filenames on up to 1024 Chars.