It appears that this relevance generated from the SWD is incorrect. Filesystem of is not correct.
(if (name of operating system starts with "Win") then (if(exist "Install.bat" of
(pathname of client folder of current site & "\__Download")) then (free space of
drive of client > 4383934) else (free space of drive of client > 6575901)) else if
((mac of it) of operating system) then (if (exist "Install.bat" of (pathname of client
folder of current site & "/__Download")) then (free space of filesystem of folder
(pathname of client) > 4383934) else (free space of filesystem of client >
6575901)) else false)
In which part? In that query for Windows it uses ‘free space of drive of client’; for Mac it uses ‘free space of filesystem of folder (pathname of client)’ ; and for others (presumably Linux) it uses ‘free space of filesystem of client’.
I don’t have a Mac handy at the moment but the Windows and Linux parts appear to evaluate correctly.
I do see a different issue in the relevance but I don’t know whether it’s related to what you’re seeing. The checks for ‘Install.bat’ are checking for the existence of the string “Install.bat” , and the string always exists; it’s not looking for the the existence of a file named “Install.bat”.
I’ll report that second part to the SWD team. but can you confirm with me which part of hte ‘filesystem’ inspector is giving you issue? Is it on Mac?
Yes, it is the Mac part.
Also, install.bat is going to bet transitory since it is part of the package download. This is something new.
Thanks, I’ll ask the SWD team to look into that as well, but ‘filesystem of <folder>’ should be valid on a Mac (but not on a Windows machine), so I wonder whether this is just an issue with the Fixlet Debugger.
Agree that the check for install.bat is new; it looks to me like their intent is probably to allow for the install packages to be on some network share somewhere instead of being downloaded by the client…the free space checks appear to be different based on whether the install.bat is already downloaded…but again that check is not doing what they’re intending, it will always return True because it’s checking the existence of a string, not the existence of a file.
I have a Task that I generated a year ago that doesn’t check that way, and when I recreate a Task from the same package today the check is there; so definitely some change to the Manage Software Distribution Dashboard within the last year.
It appears that if I evaluate using local client the relevance evaluates to true.