C:\share
是共享文件夹。C:\share\electron-v13.0.1-win32-x64
、\\192.168.1.10\share\electron-v13.0.1-win32-x64
和Z:\electron-v13.0.1-win32-x64
是同一个文件夹。
当我执行C:\share\electron-v13.0.1-win32-x64\electron.exe
命令时,Electron应用程序正确启动。但是,当我执行Z:\electron-v13.0.1-win32-x64\electron.exe
命令时,电子应用程序无法正确启动。根据任务管理器,电子进程正在运行。然而,未示出电子窗口。
电子能在共享文件夹上正确运行吗?
2条答案
按热度按时间3xiyfsfu1#
在本地使用它应该更安全(从C:\share)。Map驱动器的行为与本地文件系统非常不同。它们的实现也可以在设置上有所不同:
https://wiki.samba.org/index.php/Time_Synchronisation
https://www.truenas.com/community/threads/issue-with-modified-timestamps-on-windows-file-copy.82649/的
https://help.2brightsparks.com/support/solutions/articles/43000335953-the-last-modification-date-and-time-are-wrong的
如果我理解你只是Map回你自己的共享文件夹,总体上Windows服务器配置对我来说更一致,但是协议也随着时间的推移而改变:
https://en.wikipedia.org/wiki/Server_Message_Block的
我不太了解网络共享协议,无法给予你确切的答案,为什么你会有这个问题,但我知道的足够多,可以告诉你,挂载的共享文件夹不像你自己的本地文件系统。在许多情况下,差异并不重要,它给了很大的用户体验,但在某些情况下,这些微小的差异打破了神秘的方式,即使他们被Map/挂载几乎像一个普通/本地驱动器。这并不是Electronic独有的问题。
这是通过SMB(主要是二进制文件/工具)的很多事情的问题,共享文件夹可能运行不同的文件系统,不同的权限和特权(或者如果它是一个完全不同的文件系统,则在下面运行完全不同的权限结构)。远程文件夹可能会遇到
inotify
获取文件更新事件的问题,可能会错过更改的文件(如Linux上的touch
旨在更新文件上的日期),因此通过共享文件夹,日期更新可能会延迟/舍入。我认为在某个时候,甚至Makefile也表现不佳,因为它依赖于访问日期来按照本地的方式工作。工具的另一个问题是共享性,它能处理从同一位置运行多个示例吗?是否将某些内容保存到./tmp或其他可能与其他用户同时运行它冲突的文件中?
总的来说,我倾向于将它们用于数据共享(很少有时候也会出现问题),但只有在已知不会造成麻烦的情况下才远程共享应用程序。
jdgnovmf2#
添加
--no-sandbox
参数应该可以工作。但这面旗并不安全。