Cumulus Support

Carbonara wrote: ↑Sat 15 Jun 2024 7:02 pm yes, i need them because i've a custom cms who need to read the file …

You are not answering why you need executable permission.
You cannot execute .json and .txt files.

so, this is the log the client.txt file is a file I created with the webtags, but the same thing happens with the original realtime.txt file from cumulus, and with the json files of the graphs. At a certain point, I read that it was deleted and that recreated, or i'm wrong ? if so then it is normal for it to be loaded with 644 permissions by default. But I turned off this option in the menu. Unfortunately the ftp log does not start on the old version of cumulus

ok started the log from 3184 version, and the difference is clear , here doesn't delete anything

Well, in my eyes it looks like a bug that file is deleted before upload even when delete is disabled. I think this needs input from @mcrossley.

But actually the log from the old version looks like it is using ftp rename (file with extension .txttmp). So maybe you could achieve a similar result by enabling rename?

No, is not the rename option. Is a temporary file created by the system.

OK so it is possible that there is a bug where it deletes the file before upload even when that option is off.

However there is no reason for the data files to have the execute bit set on, in fact every FTP system I've seen does not allow the execute bit to be set on an uploaded file as it is a security exposure. I run lots of php code on my website and all that is set to 644 and that is because it is not executed directly but by (in my case) Apache which loads the code and runs it.

Stuart

hope it can be fixed

Carbonara wrote: ↑Sun 16 Jun 2024 9:21 am hope it can be fixed

Hard to say, probably yes, but it will also probably take at least a month until it will even be looked at since Mark is away for a summer vacation.

However, even many others have said before, I’ll say it too. It is extremely strange why your server requires ”5- read and execute” permissions for a text input file. It really should work with ”4-read only” since the file does not contain anything executable. So you really should investigate and fix that regardless of the possible bug in Cumulus.

I have the odd bits of time this week - none from Saturday onwards again.

You can see the request from CMX is to overwrite, but the library is doing a delete + write... Indeed looking at the FTP source code that is now the intended behaviour. I have raised an issue about this on FluentFTP.

Meantime the only solution I can think of is to try setting the destination folder permissions to 755 and the uploaded files should inherit those permissions?

Meantime the only solution I can think of is to try setting the destination folder permissions to 755 and the uploaded files should inherit those permissions?

Doesn't quite work like that. You'll need to change the umask setting for the user that is used to upload the files, and change the default to 755. That is where the perms come from. Crazy solution, though, as it shouldn't make any difference to the consumer of the file whether the execute bit is set - unless the file is to be executed. It is also a security risk, as you'll effectively set the execute bit on all files created by that user, which could be very helpful to an intruder or bad actor.

I agree, I'm still not seeing the need for the execute bit being set, but there seems to be a reason.

I am puzzled as to why the OP has not enlightened us as to the reason for the execute bit? As everyone says it is not necessary for a data file which does not contain anything executable. I must admit that I see nothing wrong here from a CMX or FTP standpoint.

Stuart

broadstairs wrote: ↑Tue 18 Jun 2024 4:05 pm I am puzzled as to why the OP has not enlightened us as to the reason for the execute bit? As everyone says it is not necessary for a data file which does not contain anything executable. I must admit that I see nothing wrong here from a CMX or FTP standpoint.

Agreed. But on the other hand, if overwrite (without delete) is requested, and yet the ftp library still does delete the file, there is definitely something wrong regardless of the specific case in hand.

I've looked further at the source code, the only way I can see currently to perform a true overwrite is to use the low-level FTP functions to open a stream directly and set the file position to zero before writing the contents. Not a hole I want to go down at the moment.

I think they changed the default behaviour because not all servers support overwriting.

OK, I have a fix for this, it will be in v4.1.1