Can I write a file to a linux directory specifying file permissions in cfscript?

Question

I have a function which writes a coldfusion query result as file to the temp directory. It works fine, and saves having to run the query so often.

However, I want to write a git hook to delete these cached files as when we push new code the data may have become stale and so should be replaced. The files are created by the apache user in 644 mode. The git user is in the same group as the apache user, so for the git user to be able to delete the files, I want to either create them in, or subsequently set them to 664 mode.

Initially I added fileSetAccessMode after the objectSave I was using:

objectSave( data, filepath );
fileSetAccessMode( filepath, '664' )

However this didn't seem to have any effect, so tried

fileWrite( filepath, data, '664' );

which also seems to write the file fine, but not set the the permissions.

I note that the Adobe Docs for fileWrite don't specify a parameter for mode, so I guess that's why that doesn't work. I much prefer cfdocs.org in general but I was quite confused by their take on the cfscript versions of cffile, as it wasn't obvious which functions used which parameters.

After some more googling, I found this cflib.org cftag style function which I guess I could borrow and reference in cfscript but I don't really want to have to do that.

What I really want to know is, can I achieve this purely in cfscript or is there a genuine difference in API functionality between script and tag? (I'm pretty sure this is the case in other instances).

Very grateful for any input.

Answer 1

After taking a break and coming back to this, I discovered that I can use

fileSetAccessMode( file, '664' );

In cfscript, and embarrassingly I had it in the wrong place in my code. However, it is still necessary to do that separately having created the file previously because

fileWrite( file, content );

doesn't support the "mode" parameter as in

<cffile action="write" file="file" output="content" mode="664">

having consulted with some wiser members of the community, I have filed this as a bug with Adobe.