Altui file not found errors
-
@buxton said in Altui file not found errors:
the full path did work for more than a year...
I have no explanation for how that could be.
@buxton said in Altui file not found errors:
that still leaves the issue of why the path as seen in the log is different from the actual path being used
I don’t understand this. It isn’t. It’s the actual path used by the open routine (which is relative to the base folder.)
@buxton said:
Can you make the "file not found" error a red highlit error like the other system errors.
Yes, I’d planned to do that, but it happens rather often in a benign way, for example, the browser often tries to get favicon.ico, but if you haven’t got one, it keeps trying…
The console HTTP has a list of all file requests and their latest status.
@akbooer My apologies for not being clear. I'll try to explain what I mean with the following screen shots. The folder holding the localcdn files is "/etc/cmh-ludl/localcdn/"
A sample error message in openLuup is:
file not found:etc/cmh-ludl/localcdn/joint.css
The two paths are identical. Because the two paths are expressed as the same, the impression that one gets from the log is that the actual files in the folder are somehow not accessible to the calling program.
Because files are retrieved from a relative position to the base folder, the actual path that is being called is probably: /etc/cmh-ludl/etc/cmh-ludl/localcdn/joint.css. If I saw the below path in the error log, I would immediately understand why the files were not being found:
file not found:etc/cmh-ludl/etc/cmh-ludl/localcdn/joint.css
Knowing now that the underlying problem was relative paths, the issue is not really a concern for me. And I completely understand the need for relative paths given the chaotic working folder structure on a vera device--and the need to account for this structure in a more rational manner in openLuup. However, others may encounter similar file not found error messages, and be completely flummoxed as to why files that are obviously showing as being in a proper folder, are then not found by the calling function.
Displaying the full path in the log would give an immediate understanding of why the error is occurring. As for why the original path worked for so long, my guess is that the lua routine walked the path in various ways, and found the files. Why it broke is a mystery, perhaps a more restrictive linux update -- I usually do an OS update when I update openLuup.