View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0021663 | MMW 5 | General | public | 2025-06-20 22:21 | 2025-06-21 10:23 |
| Reporter | zvezdan | Assigned To | |||
| Priority | none | Severity | minor | Reproducibility | N/A |
| Status | feedback | Resolution | open | ||
| Summary | 0021663: Problems with filesystem and network drives | ||||
| Description | 1. Non-existing drive reports as observable having subfolders: app.filesystem.networkResourceFromPath("\\\\EhkjhjkLE\\").hasSubfolders; -> returns true app.filesystem.networkResourceFromPath("\\\\EhkjhjkLE\\").isObservable; -> returns true 2. I cannot see my network drive and its shared folders in the Folders > Network nor in its Microsoft Windows Network subfolder in the Tree panel, nor in the Select folder dialog box. 3. However, I see non-existent network drives that are stored in the database, even if it is not my own database, but from another user (although such drive cannot be expanded, just shows "Loading" on such attempt). Windows File Explorer is showing my network drives correctly. The next part of the original post could be removed, it is leaved here just for a reference: ---------- - Existing "ABC" network drive reports as non-existent: await app.filesystem.dirExistsAsync("\\\\ABC\\"); -> returns false; EDIT: scratch this. The same problem is with VBScript (WSH): Dim oFileObj: Set oFileObj = CreateObject("Scripting.FileSystemObject"): WScript.Echo oFileObj.FolderExists("\\ABC\") - Some existing subfolders are fine, but not all (I didn't find any pattern for such behavior): await app.filesystem.dirExistsAsync("\\\\ABC\\Shared\\"); -> returns true as it should await app.filesystem.dirExistsAsync("\\\\ABC\\Users\\John Doe\\Music\\Radio\\Orbital\\"); -> returns false await app.filesystem.dirExistsAsync("\\\\ABC\\Users\\John Doe\\AppData\\Local\\Mozilla\\Firefox\\"); -> returns true as it should EDIT: scratch this too, I cannot reproduce it anymore. - dirExistsAsync takes too long with non-existent folders: await app.filesystem.dirExistsAsync("\\\\hsjfkjdhfjkses\\data\\media\\music\\dert\\asdfd\\"); -> 7 sec await app.filesystem.dirExistsAsync("\\\\192.168.1.201\\data\\media\\music\\dert\\asdfd\\"); -> 30 sec It seems it works longer with longer paths. Sometimes it returns immediately when applied with the same path for the second or third time, but it is slow again for the forth or fifth time. EDIT: scratch this too. The same timings are with VBScript, e.g: Dim oFileObj: Set oFileObj = CreateObject("Scripting.FileSystemObject"): WScript.Echo oFileObj.FolderExists("\\192.168.1.201\data\media\music\dert\asdfd\") ---------- | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Please note that Windows networking is based on NetBIOS resolution and MasterBrowser Election. NETBIOS over TCP/IP is most certainly still supported in Windows Vista and above. You can see this in the TCP/IP settings on your adapter. There is still a spot to add WINS server addresses. That said, DNS is the modern/preferred named resolution method (Often handled by Routers alongside DHCP Server), however NETBIOS is still around for compatibility with legacy applications and/or networks. https://smallvoid.com/article/windows-master-browser.html https://borncity.com/win/2022/04/25/microsoft-lsst-netbios-namensauflsung-und-llmnr-zuknftig-auslaufen/ https://answers.microsoft.com/en-us/windows/forum/all/netbios-over-tcp-ip-windows-10-cant-enable-it-now/60c73b04-e446-47a6-ba70-39dd7a73d717 Delay in accessing/checking network shares is that with SMB2/3/4, Bonjour, NFS there is additional security and permission checks if user can/can't access shared resource or network device eg. if you try to save TXT document on network device \\ABC\ and its share folder \documents\ often there is delay of accessing \\ABC\ due the checks in order to get list of available shares. Also await app.filesystem.dirExistsAsync("\\\\ABC\\"); always fail as "\\ABC\" is not folder but Device designation while \\ABC\data\is shared folder (same as C: is not folder but drive definition but C:\ is folder). also you can't MAP \\ABC\ but you can MAP \\ABC\data\ Behavior I observed is that direct access \\ABC\data\ will be more faster than accessing \\ABC\ -> double click on \data\ (eg. "\\ABC\data\") due the less security checks. Why we added https://www.mediamonkey.com/support/knowledge-base/mediamonkey-database/problems-scanning-networked-files/ which is workaround. |
|
|
1. We will check that EDIT: checked, if \\ABC\ exists then observable and apparently no shared folders listed or folders are hidden say false as Device exists because if it say false you will not be able to access hidden shares even with direct access eg. \\ABC\hiddenshare\ 2. See my previous reply 3. That is also normal due the https://www.mediamonkey.com/support/knowledge-base/mediamonkey-database/problems-scanning-networked-files/ Please add more details while we test 1. |
|
|
@Peke: Thanks for such detailed answer. 1. I am not sure that understand your EDIT. I figured out already there is my fault specifying just a device name without shared folder name. However, in my opinion, this should not return true: app.filesystem.networkResourceFromPath("\\\\EhkjhjkLE\\data\\").hasSubfolders; What is the point of that method if it always returns true? 2. I have an add-on with the Scan folder dialog box that allows specifying folders for its users. Your solution with manual copying/pasting strings from File Explorer into Add/Scan dialog is not applicable to it. 3. The Folder node in the Tree panel and Scan folder dialog box should display only psychically available drives, not those that are presented in the current database. Such drives/folders should be visible only in the Location subfolder of the Entire Library node or other collections. MM4 didn't have such behavior. |
