I'm guessing here:
Paths on local Windows systems are typically
driveletter:folder\folder\...\file.extension
Window scan use UNC paths, such as:
|\\Server2\Share\Test\Foo.txt|
||
When we had our first customer who was extensively using UNC paths, our
software broke until we updated it to allow for both style of Windows
paths to be handled properly.
Windows backslash \ gets converted to a / in most LC file paths (for
example, the result of a open or save file dialog
Perhaps the IT did something to require only UNC paths and the // after
the binfile had it look for a server rather than a local file?
On 8/13/2024 4:24 PM, Ben Rubinstein via use-livecode wrote:
An app running nightly by schedule on a Windows VM stopped working
when the IT department cracked down on security, downgrading the
privileges of the user. When this was reversed - and they swore there
were no other changes - it still didn't work properly because it
failed to read some local data files.
It turned out that the issue was that I was reading the data as
put URL format("binfile://%s", tPath) into tData
this was working, but now returned "can't open file". Changing the
statement to
put URL format("binfile:%s", tPath) into tData
fixed the issue, so it's fine. But my question would be does anyone
know what would have changed on the system to make this statement,
that used to work, do so no longer?
Many thanks,
Ben
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
