Hello, Mirek.
I researched the problem and found that there are different .lnk files on my desktop.
I attached three of them.
The file СТМ32.lnk points to local directory and it works OK.
Other two files point to network and don't work (they are opened as empty files).
All the .lnk files are shown as files, not as folders (it would be better).
Best regards,
Victor
#include <CtrlLib/CtrlLib.h> using namespace Upp; GUI_APP_MAIN { String path = "C:/Users/cxl/Desktop/Files.lnk"; DDUMP(path); DDUMP(FileExists(path)); String t = GetSymLinkPath(path); DDUMP(t); DDUMP(DirectoryExists(t)); }
Can you test this for me:
#include <CtrlLib/CtrlLib.h> using namespace Upp; GUI_APP_MAIN { String path = "C:/Users/cxl/Desktop/Files.lnk"; DDUMP(path); DDUMP(FileExists(path)); String t = GetSymLinkPath(path); DDUMP(t); DDUMP(DirectoryExists(t)); }
path = C:/Documents and Settings/pva/Desktop/СТМ32.lnk FileExists(path) = true t = D:\_STM32 DirectoryExists(t) = true path = C:/Documents and Settings/pva/Desktop/Files.lnk FileExists(path) = true t = \\1336data\Файлообменник DirectoryExists(t) = false path = C:/Documents and Settings/pva/Desktop/Файлообменник.lnk FileExists(path) = true t = \\1336data\Файлообменник DirectoryExists(t) = false
Hello, Mirek.
Here's the log:
path = C:/Documents and Settings/pva/Desktop/СТМ32.lnk FileExists(path) = true t = D:\_STM32 DirectoryExists(t) = true path = C:/Documents and Settings/pva/Desktop/Files.lnk FileExists(path) = true t = \\1336data\Файлообменник DirectoryExists(t) = false path = C:/Documents and Settings/pva/Desktop/Файлообменник.lnk FileExists(path) = true t = \\1336data\Файлообменник DirectoryExists(t) = false
Victor
Assuming that "\\1336data\Файлообменник" is a correct path to network share, one possible explanation is that the problem is somewhat caused by those azbuka characters. Would it be possible to create some link to network without azbuka just to test?
Mirek
path = C:/Documents and Settings/pva/Desktop/Constructor.lnk FileExists(path) = true t = \\1336data\Constructor DirectoryExists(t) = false
bool FindFile::Search(const char *name) { pattern = GetFileName(name); path = NormalizePath(GetFileDirectory(name)); Close(); handle = FindFirstFileW(ToSystemCharsetW(name), data); if(handle == INVALID_HANDLE_VALUE) return false; <-- returns here if(!PatternMatch(pattern, GetName())) return Next(); return true; }
Mirek, I looked at it in debugger.
File: Path.cpp
bool FindFile::Search(const char *name) { pattern = GetFileName(name); path = NormalizePath(GetFileDirectory(name)); Close(); handle = FindFirstFileW(ToSystemCharsetW(name), data); if(handle == INVALID_HANDLE_VALUE) return false; <-- returns here if(!PatternMatch(pattern, GetName())) return Next(); return true; }
name contains "\\\\1336data\\Constructor"
Victor
Maybe we can try something like
FindFile ff("\\\\1336data\\Constructor\\*.*");
while(ff) {
DDUMP(ff.GetPath());
ff.Next();
}
ff.GetPath() = \\1336data\Constructor\. ff.GetPath() = \\1336data\Constructor\.. ff.GetPath() = \\1336data\Constructor\constructor
mirek wrote on Fri, 08 November 2019 12:15Maybe we can try something like
FindFile ff("\\\\1336data\\Constructor\\*.*");
while(ff) {
DDUMP(ff.GetPath());
ff.Next();
}
ff.GetPath() = \\1336data\Constructor\. ff.GetPath() = \\1336data\Constructor\.. ff.GetPath() = \\1336data\Constructor\constructor
It's correct.
OK, thats interesting. I guess it should not hurt anything if we change DirectoryExists to this method - commited in trunk.
Can you please check with trunk how FileSel behaves now?
Mirek
mirek wrote on Fri, 08 November 2019 12:51
OK, thats interesting. I guess it should not hurt anything if we change DirectoryExists to this method - commited in trunk.
Can you please check with trunk how FileSel behaves now?
Mirek
It works OK.
Only one thing: when opening files with file mask, it shouldn't show shortcuts, pointing to local files that don't match the mask.
Thank you,
Victor
That would require resolving .lnk on directory load. I am afraid that would lead to unresponsive GUI in cases when .lnk leads to network share...
mirek wrote on Fri, 08 November 2019 16:23
That would require resolving .lnk on directory load. I am afraid that would lead to unresponsive GUI in cases when .lnk leads to network share...
The everage user has dozens shortcuts on the desktop. The majority of them point to installed programs and other local files. And only a few of them lead to network drives. I would not want to force users to look for the right label among many wrong ones.
Best regards.
Victor
Well, but those 'few' can freeze directory loads for minutes...
mirek wrote on Fri, 08 November 2019 18:52
Well, but those 'few' can freeze directory loads for minutes...
BTW, links to files and directories have different icons, i.e. they are resolved already.