Hello,

I would like to know if it is possible to make the PhpED editor read-only for all files?

As this editor is known to break file permissions on local files or local shares (cf. bug report [NU SUPPORT #GFP-925196], dated from last September), which is a big problem on CLI debugging, I never use it and I need to always modify my files from an external editor.
But I need to use it when doing debugging, and it is easy to mistakenly modify files that way if you don't think about it all the time.
So I would like to know if there is a way to block any modifications to any files from the PhpED IDE?

Regards,

Gingko

When you save a file in the IDE, it is performed in the following way
- IDE creates *new* file with temporary name, say filename_A.tmp.php
- saves the content into it
- renames old/existing file, say filename_A.php => filename_A.old.php
- renames new file to filename_A.tmp.php => filename_A.php
This is the safest way that minimizes the risk of loosing file(s) and many products works in exactly the same way with minimum variations.

As of permissions -- under Windows all new files inherit permissions from the directory where they are created.
Note that the owner will be set to the user account under which you're running the IDE. So if the directory has different owner, the permissions may be different. In this case I'd recommend you to take / re-take ownership.

With uploads / downloads it works differently. If you open remote file using SFTP/SSH or FTP or WebDAV account, edit it and save, IDE will upload it directly in-place because it's known that in many cases user account won't be able to create new file and the schema listed above wouldn't work. In this case permissions can never be affected at all.

Regarding blocking modifications -- just don't press Save button and make sure that Auto Save option is not checked on Tools->Settings->IDE Settings or it will save all modified files when you start debugging in the IDE. If you don't trust yourself, you can block modifications at the OS level by setting file permissions that won't allow you to make any changes. It's even easier to do if you work with files using remote accounts.

I'm not running scripts under Windows.

My scripts are running under Linux, but I am debugging them using PhpED (itself running under Windows, of course), and I access them through a network share (provided by Samba under Linux).

Permissions under Linux include the execute bit, which is needed in order to have the script able to run. And this execute bit is broken by PhpED too.

This means that I have to reapply permissions each time I change even a simple comma otherwise the script will simply not RUN.

By the way, apart breaking permissions, this way of saving also breaks symbolic links and hard links. This is sometimes also an issue for me.

For that reason, I can't use the PhpED editor, and I edit my scripts with an external editor which do not use the same method of saving. This editor makes backup copies before saving instead, but anyway I must say that I never met the case of loosing files with it in more than 15 years of usage.

Blocking modifications at OS level is not a solution either. It would also block modifications made with my other editor which is certainly not what I want.

I could eventually also access the file using a remote account, but in this case I would loose the huge advantage of not having to synchronize files after each change.

Gingko

All of my projects are stored on Linux file systems and accessed using Samba shares.

If I create a new file from PhpED then the ownership is incorrect. Fair enough because it is the owner of the Samba share rather than the project files. It doesn't generally cause me a problem in this case and fortunately the default permissions are fine, but every so often I do have to change ownership.

If I edit an existing file in the project that already has correct ownership and even if it has special permissions, those are always retained when I save the file. I just tested that to confirm.

In theory I wouldn't expect that to work with the new/save/rename method that Dmitri indicated, I would only expect it with an overwrite, but nonetheless it works. Not sure if Samba has something to do with that.

I might do a monitor on Samba to see what it does when a file is saved.

It does not make any difference. You can setup remote project and run your cli scripts under linux or any other supported platform where you have SSH access.



Just FTR regarding execute bit -- yes there is such bit and no, this bit is not required -- you can run /path/to/php /path/to/your/script.php.
In particular when PhpED runs your script remotely it uses this method.
Still, if you setup remote project -- WITHOUT any Samba -- just WITH ssh account, the permissions won't be altered because, as I said above, the files are uploaded via ssh/sftp in-place.

I DO use remote projects if I want to debug from one of my four really remote servers.

But I also have a test server, which is a Linux computer located about one meter from my working Windows computer.

As much as I can, I prefer debugging from there because it is far quicker, easier and less error prone than having to constantly sync between remote files and local copies.

Or at least it should be easier … if only there wouldn't be this permissions problem …

Gingko

Wouldn't it be possible anyway to consider implementing both methods (the current one, plus another one like <create backup copy in the same directory / save the file in place / check if it was properly saved / delete the backup copy if checked successful>), and allow users to choose which one they prefer in the global settings dialog?

In addition to that, you could also add to the current method the ability to copy the file ownership and permissions from the old file to the new one.

Regards,

Gingko

P.S.: By the way, I just renamed the topic with a more appropriate name.

Permissions can't be copied because Samba is all about Windows Share API. It does not provide any way to manipulate native OS permissions. Don't blame PhpED for that.

Actually you can probably.

Linux permissions seems to be mapped to something equivalent in Windows ACLs when accessed through Samba.

I just made a test by accessing a file located in the Linux filesystem, starting from Windows and the network share (by right-clicking the file, getting “Properties” and next the Security tab).
From the security dialog I have perfectly be able to set permissions (including the “execute” bit) the Windows way, for User, Group and Everyone, et verify that these changes are effectively reflected on the drwxrwxrwx flags set.

If the Windows Explorer (at least on Windows 10) can do that, I can't imagine that it couldn't be done from a Windows application using the Windows ACLs Api.

Likely you could consider reading all permissions you can from the source file using the Windows API, and nearly blindly write them to the new file, even through a Samba network share.

Otherwise you could anyway consider implementing the other method of saving, as an alternative that users could choose or not.

Gingko

These permissions are preserved. Try to open file, edit it and save. Permissions will remain the same. If SAMBA do not properly translate them for you, it's up to Samba.
New files and/or the files produced with File->Save As will have default permissions and you'd take care of such files yourself if you need some custom permissions other than Windows assigned by default.

I just made more advanced testing.

Finally it appears that I generalized too much.
The real thing is stranger : actually, permissions are preserved.

Except one : the execute bit for owner (but the execute bit for group and the execute bit for everybody are preserved).

This is still a bug, but sligthly different from what I thought.
Especially knowing that this bit is one of the most critical to keep.

None of the other text editors that I could use breaks this bit (not even notepad.exe).

Gingko

You may want to ask Samba guys. I have no idea what causes Samba to drop any bits on the remote file system. Definitely PhpED can not do this.
Even though it "works" in some other applications, it does not mean the problem is in PhpED.