How do I set up Perforce with Composer so that files such as the vendor folder are not writable by Perforce?
For example the composer lock file.
Three options (you can do any or all of these):
Add these files to your P4IGNORE. That will stop you from adding them.
Remove these files from your client view. That will stop you from adding them OR syncing them.
Remove these files from the protections table (this requires you to be an admin). That will stop ANYONE from adding them.
Related
I'm working in a group using GitHub, and when I tried transferring my work to the remote repo it didn't allow me to. It says I must do git pull first, so I did. That created some conflict in my code, then I tried to do git push again and that didn't work either.
So I switched to a new branch and tried to push from there. Didn't work with a simple git push, but a similar instruction worked for me.
Since then cmder keeps showing this:
C:\laragon\bin\cmder\vendor/clink.lua:219: attempt to index local 'HEAD' (a nil value)
C:\laragon\www\pharmacie>
Which allows me only to use instructions like php artisan serve, but not Git instructions like git status...
I already tried some clink.lua code that I found on github, but didn't work.
I tried abandoning my project, so I cloned the remote repo locally.
But then it didn't clone the vendor folder or the .env file; so I added them from an other repo (so it could compile) and changed the DB name in the .env file to match my project.
Now it keeps giving an error that says the table of the project I got vendor + .env from doesn't exist. But I didn't leave that table in the .env, I changed it to my project.
Any help?
Your problem is probably due to a conflict in a file you didn't handle.
When there is a conflict, a file usually looks like this:
<<<<<<<<< HEAD
// Some code
==============
// Some other code
>>>>>>>>> branch
And you have to choose what you want to save and what you want to delete after the merge.
So I would recommend to you to check your C:\laragon\bin\cmder\vendor/clink.lua file at line 219 to see if it could contain what I just said above.
And by the way, you should add your vendor folder in your .gitignore
And for the problem with your .env file, did you run php artisan migrate ?
EDIT
And because the problem come from your vendor folder, you could resolve it by deleting your vendor folder and run composer install to reinstall your dependencies
I have been facing the same issue. I resolve the issue by updating the cmder.
As like the image above for that click on the upper right corner (Setting) on the cmder window.
1. Choose: General -> Update
2. Check the Startup checkbox for (Do automatic check on) and then
3. Click the save settings button
4. Restart the cmder.
5. It will prompt for update and allow it to update.
6. Restart cmder again and it will resolve the issue.
I repair it as follows:
clone the repository again into another folder
access the hidden .git folder and copy only the folders (hooks, info, logs ...), do not copy the files
replace the folders in the .bin folder of the newly cloned project with the old one
with this I recover the branches and the code of my project, I hope and it will be useful to someone.
Using Laravel Framework 5.5.0.
The /var/app/current/storage/framework/views folder is constantly getting deleted.
Has anyone experienced this behavior or know why this would be happening?
*Also worth noting I attempted to circumvent this by setting the immutable flag on the directory but then my frontend stoped working.
Looks like the folder is getting deleted because there is no files tracked by git inside.
Try to add .gitignore to the storage/framework/views with the following content:
*
!.gitignore
Then remove all gitigore rules for views folder in root .gitignore.
You should be able to add this file to git index and commit. The problem should be fixed after next deploy.
See: How can I add an empty directory to a Git repository?
This is really weird.
I am trying a clean Teamcity 9.1.1 install but the Data Directory is nowhere to be found.
if I access the Global Settings tab under Administration, it lists "C:\Windows\System32\config\systemprofile.BuildServer" - a folder that doesn't exist.
if I try to browse to that folder, it shows me a range of files; uploading a specific file there instead uploads it to C:\Windows\SysWOW64\config\systemprofile.BuildServer.
there is no teamcity-startup.properties file anywhere - I am unable to customize the location of the data directory.
when I restore a backup, the backup files are instead restored to C:\Users\[user name]\.BuildServer rather than in the correct data directory.
Does anyone has any suggestions on how to regain control of the situation? How can I tell TeamCity which data folder to use?
I resolved the situation by:
stopping TC services;
creating a teamcity-startup.properties in [install folder]\conf with the following content:
teamcity.data.path=D:\\[install folder]\\config
restarting TC services;
restoring my backup.
This restored the 9.1.1 install as well as stabilizing the location of the data directory. After this was done, the subsequent installation of 9.1.7 prompted me to uninstall 9.1.1 first (which it hadn’t done the first time around) and the upgrade succeeded.
I believe the system was already compromised at the beginning, unknown to me, due to the data folder being all over the place. Once that was resolved, everything else fell into place.
When I try to install any component, specifically my mtwMigrator component, I receive the following error:
* Warning! Failed to move file.
This is on a fresh install, with FTP Layer turned off, with default content installed, Joomla 1.5.14, latest PHP and my_SQL versions, Legacy mode turned on.
A very common cause of this error is due to file permissions. Joomla must be able to copy the files from your component into the components and administrator/components directories. If the system user the webserver runs as does not have write permissions to these folders, it will not be able to copy the files over.
The FTP layer is there to get around this issue. With the FTP layer on, you upload the component to the server first, then it is FTP'ed from the temporary directory to localhost. For this to work, the FTP user you specify must have permission to write to the components and administrator/components folders.
I had a similar problem when moving between machines (I know you said it was a fresh install - but someone might find this helpful). Ensure the $tmp_path entry in joomla\configuration.php is pointing to a valid directory. Mine wasn't.
In your Joomla backend, on the top menu, go to Help >> System Info >> Directory Permission and ensure that that are writable otherwise you don't want to have to change the folders to 777 and back again each time you install an extension.
In addition to this, you can mass chmod folders and files using Akeeba Admin Tools.
You mgiht also want to update to the latest Joomla 1.5 version (1.5.26)
The most ideal permission for Joomla directories is 755. There are cases when mod_suphp is not installed that the permission problem would occur.
Make sure that mod_suphp is installed and loaded by checking your php info e.g. and running this on your browser. If mod_suphp is not installed, then you will need help from your hosting provider to install this for you.
Normally, all directerories should have 755 (rwxr-xr-x) and all files 644 (rw-r--r--). If you want to set the most directories to not-writetable, you will need at least the directories listed in Help > System info > Directory Permissions. (Here you can also check which directories need to be changed, as non-writetable directories are shown in red.)
In some shared hosting environments, 755 / 644 isn't enough, as the owner of the file is not the (Web)Server User, but the FTP-User ... so either change it to 777 / 666 (not recommended, as you allow others to write your files), or get your FTP layer to work.
Another try: Joomla! does not work yet with the recent PHP 5.3. Can you use PHP 5.2? (Similar Problem in the Joomla Forum)
I've a windows service that updates our product. It copies the product files into a temp directory, usually "C:\Windows\Temp", patches the binaries, and then uses MoveFileEx to copy the files back to the install directory on a reboot, usually "C:\Program Files\Product". The files in the install directory are inheriting their security attributes from the parent folder. After the copy, patch, and reboot, the files in the install directory are missing some ACLs. Specifically the files don't have the ACL for the Users group anymore so users can no longer run the program after the reboot.
Can anyone explain whats going on here? It seems that copying from the install directory to the temp directory, the files inherit the ACLs of the temp directory. On the MoveFileEx/Reboot, though, the files only inherit the ACLs that both the install and temp directories have in common.
In Windows if you copy a file the file takes on the ACLs of the destination directory. If you move a file the ACL goes with it overriding any it might inherit from that directory. I'm not sure how MoveFileEx might operate differently on a file.
The temp directory is usually located under the user profile (both %TMP% and %TEMP% usually point here) so copying files here will have permissions for that user. Moving those files to the program files directory will take only that users rights with them and therefore only runnable by the installing user.
One potential workaround is to patch copies of the files with-in the same directory but with different names. After the reboot, the patched versions could be swapped in. Alternatively, do a reboot first and then patch them in-place, and just back them up to the temp directory in the event a manual rollback is required.
If you really want to move them to a different location, creating a temp folder in the same place as the files to be patched would help the permissions stay the same assuming the directory is using inherited permissions.