A Windows weirdness

[Paul Dupuis]

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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode