Do you have a test case that can be used to reproduce?
You can file an Issue at Haiku Archives for Paladin.
Hey, where is a TAGs and Issu’es in this acount from Adam?
Issues:
Most of the maintainers will look there.
@cocobean… You need to go to the site and tell me that the maintainers are actively maintaining Paladin there. All the latest changes and updates are on the HaikuArchives Paladin Github site in the “develop” branch waiting to be merged. File issues there.
2 Likes
To-Do:
- Promote ‘develop’ branch to ‘master’.
- Migrate/merge existing Paladin ‘issues’ in adam’s fork to HaikuArchives/Paladin.
- Tag stable release(s).
4 Likes
100% agree on those next step items.
Hi,
I encounter a trouble with Paladin IDE, some people had encouter this one.
When I create a new project all files from the new project are in read only mode so I can’t edit it. The only way I find for counter it, is to edit manually every files propreties. There is another way for counter it (most quickly)?
Paladin version 2.8~git-3
----------------Edit--------------------
Ok, I answer to myself, launch a terminal in the folder of the sources and type it:
chmod +w *
But why Paladin is not doing this by himself?
1 Like
The source files of the examples are in packages, thus read only. Paladin just copies them and forgets to change the permission bits.
2 Likes
That does not seem correct. While packagefs is mounted read-only, that shouldn’t change the file permissions that are stored on disk.
So if the files in the package are stored with read-write permissions (even if not allowed by the packagefs mount), these read-write permissions should be inherited by the copy.
1 Like
iirc packagefs exposed them RO, if you say it does not do this then the packaged files may have the wrong permission bits set initially.
1 Like
Indeed it looks like nothing in packagefs has the write permission bit set. Seems like a bug or enhancement request to me?
1 Like
I thought that was intentional so tools do not try to write to it : )
There is a distinction between writing to a read-only file (this should return an EPERM error) and a read-only filesystem (this should return EROFS). I don’t think we need both here, and now we have an use case for packagefs to preserve the write permission, even if it does not seem to do so at the moment.
1 Like
Maybe a leftover safety net to secure the templates from accidentally overwrite from the pre-PM time?