FileExists behavior inconsistent with ACF

Description

The Lucee implementation of FileExists produces results which are inconsistent with the ACF implementation when the given 'source' argument is a valid relative path but not a valid absolute path (i.e. the path is only valid if ExpandPath() is used)

Consistent results are obtained if the optional second argument 'allowRealPath' is explicitly passed as FALSE, but code written with this argument won't compile under ACF

https://docs.lucee.org/reference/functions/fileexists.html

For clarity, this argument should be renamed to 'allowRelativePath'. Description in documentation should be updated to something like:
'boolean indicating whether the source argument may be a relative path. If false, the returned value will only be true if the source is a valid absolute path. If true, the returned value will also be true if ExpandPath(source) returns a valid absolute path

For improved functionality, this argument should be replaced with a string argument named 'pathType' which accepts one of three values:
'absoluteOnly' (file path interpreted as absolute, must be default for ACF compatibility)
'relativeOnly' (file path interpreted as relative to a mapping - equivalent to calling FileExists(ExpandPath(source)) in ACF
'relativeAllowed' (source checked as absolute first, then as relative if absolute path isn't found)

=============

To reproduce in a Linux environment:

1) configure a mapping '/issues/' which resolves to a local directory such as '/home/content/public/issues/'
2) put a file 'foo.txt' into this directory
3) run the following code on Lucee and ACF - observe different results:

WriteOutput(FileExists("/issues/foo.txt"));

// Lucee returns 'true', ACF returns false

WriteOutput(FileExists("/issues/foo.txt",false));

// Lucee returns 'false', ACF returns error 'Parameter validation error for the FILEEXISTS function'

Activity

Show:

Tim Parker 2 December 2021 at 16:01

Path arguments to Lucee-provided methods may transparently allow relative paths, but this will never extend to Java-native methods. For example:

iio = CreateObject("java","javax.imageio.ImageIO");
srcFile = CreateObject("java","java.io.File").init(srcPath);
bi = iio.read(srcFile);

 

I can see desire to be ‘friendly’ and allow relative paths in places where ACF implements (and documents) ‘absolute paths only’, but this can easily result in unintended and unfriendly consequences.

Pothys - MitrahSoft 2 December 2021 at 12:06

I've checked this ticket with the lucee latest version 5.3.9.14-SNAPSHOT. Yes, using mapping/relative path in FileExists() have Incompatibility with ACF. Lucee returns true for that but ACF returns false.

fileRead() with mapping/relative path and the absolute path works in lucee. But it works only with absolute path in ACF and ACF throws an error for mapping/relative path. So as per fileRead() behaviours fileExists() returns expected result in both lucee and ACF. Anyway, will decide about this issue.

Tim Parker 2 December 2021 at 01:05

I wrote this up as an incompatibility, but I’ll argue that it’s actually a bug - as currently implemented, the default behavior (i.e. called without the optional second argument) does not accurately indicate whether a path can be used as the ‘source’ argument to CFFile (action=read)

 

and… yes, there is a work-around to the ACF compiler problem, but it’s ugly:

args = StructNew();

args.source = pathToTest;

if (Lucee)

args.allowRealPath = false;

result = FileExists(ArgumentCollection=args);

Details

Assignee

Reporter

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Priority

Created 2 December 2021 at 00:57
Updated 2 December 2021 at 16:01