I am building an openwrt firmware for an old mt7620 board for commercial purpose (captive portal)
I am encountering a strange behaviour when I try to save updated config files. I am trying to figure out the reason.
This is an example of what happens :
1 – FIRST TRIAL :
I compiled an old Chaos Calmer 15.01 openwrt version. From the console, I go to the /overlay/upper/etc/config:
Before reboot
I modify or delete the existing files in the [..]/etc/config/ folder
I create a new file for example "test" in [..]/etc/config/
I create a folder "new_folder" with a file inside
After reboot:
changes are not kept or deleted files are back in [..]/etc/config/ folder
the new file for example "test" is still there
the "new_folder" with its file inside are still there
Finally :
if I delete the new files "test" and "new_folder", after the reboot they are effectively deleted
So to sum-up : only pre-existing files in [..]/etc/config/ folder are reverted back at each reboot.
2 – SECOND TRIAL :
I compiled a firmware of the same version without UCI, when I modify the files in /etc/config/, changes made manually are kept after reboot, except 'wireless' which revert to its initial state.
It seems like some process involving UCI at startup use the original files and not the edited ones.
I took a look to the .sh scripts in /etc/init.d, /etc/rc.d, lib/config, lib/functions, lib/preinit... to see what is going on but its still not clear when and where config files are processed (even after looking at topics on the subject)
3 – THIRD TRIAL :
I managed to compile another firmware based on LEDE 17.01 to see if there are benefits. Unfortunately, I still have the same problem concerning the files in the /etc/config which always revert to their default value.
4 - FINALLY TO SUM-UP :
Is there a way to turn this behaviour off, or is it a kind of 'file protection' towards something that could be seen as 'currupted' by the system ?
Note :
I know that theses versions are very old and some people may recommend to upgrade it.
But, In regards to my constraints, I tried to update to openwrt versions >= 18.06. Each time I have kernel panics even by compiling with the custom changes I made that work with the previous versions (DTS file).
So, I am stuck with it for instance, I prefer having one problem at a time.
Sorry for the long post.
Thanks a lot, by advance, If someone have an idea or have already seen such a situation.
Best Regards.
Edit : Overlay at boot time
Overlay at boot time
Related
I am having this weird problem, in a certain Laravel project where some files are just deleted or renamed weirdly. I am the only user on the machine, I have other projects too but I haven't seen anything like this happen to any of these other projects.
I've also noticed that the files being deleted or renamed are the same, I have been using git to control revert back to the stable state but now this is becoming nuisance and thus have decided to seek help around here. Any help will be appreciated.
Periodically I launch my app from Xcode to find Core Data errors due to an empty model file. The versioned model files are found in the main bundle but the model file still inits to nil. See my answer for partial workarounds but no solution to date.
I've verified that the files exist and are accessible using the access function. I've tried using initWithContentsOfURL and mergedModelFromBundles with the same result.
This happens randomly and I suspect something is changing the model file behind the scenes but I don't know what.
Restarting my computer seems to have solved the security related crash but this also necessitates removing the existing Core Data store file as it complains the existing one doesn't match the model file.
[UPDATE]
Restarting does not solve the problem. But reseting the current version of the Core Data model file did the trick. I changed it to an older version and then back. This question helped me think of this as something to try. Using mergedModelFromBundles: and versioning (CoreData) Still not sure what the root problem is.
[ANOTHER UPDATE]
I put a file monitor on the .xccurrentversion file in my Core Data momd file bundle to observe when the file is being touched. I've noticed that XCode (or some build tool) updates the .xccurrentversion file periodically when XCode comes to foreground (either when the project is opened or when it's been in background for a while). When it did this today it updated the file setting _XCCurrentVersionName to the main momd file bundle rather than the version file. I replaced the .xccurrentversion file with an older version and it launched. This would explain why reseting the current model version fixes this issue. I have no idea what the conditions are for XCode to update this file.
Im finding myself using TextMate 2 more and more for development these days
One thing that is bugging me is that it does not seem to reload a file when it is changed externally.
This is a big problem since I use terminal to switch git branches a lot, and it often results in accidentally saving an older version over the new branch
Sadly the TM team seem to have disabled the Issue tracker on github, and documentation just seems scattered far and wide over the web in tiny scraps.
Any ideas?
Right now it reloads the file silently whenever the file on Disk is changed. There is currently no option for a prompt.
Regarding the closed issue tracker: As an alternative, you can always send a mail to the Textmate users list if you find a problem.
I just updated to TM 2. In the past, I have enjoyed using TM to view development.log as I am introducing new or modified code. TM 1 would ask me if I want to revert to what's on disk and of course I would respond with Yes. Then I could see any additions to the log file. Occasionally I would empty the log file with Cmd+A, Delete, Cmd+S. Macromates, please make TM 2 work like TM 1 reloading content.
I also could not find a solution to this problem which is still there, however it is possible to file an issue using this contact page: http://macromates.com/support
Additionally there are hidden setting which cannot be set from the GUI. Unfortunately they don't include and setting for automatic load from disk: https://github.com/textmate/textmate/wiki/Hidden-Settings
I don't recall having this problem before I migrated to my Retina MacBook Pro, but since doing so, my projects have insisted on loading in the "old" development location. In years past, before XCode 4, we put all our products in /Development/Products. And, after migrating to the new MacBook Pro, they're going back there again. I can use 4.3 or newer and see the same problem with both, so I'm assuming it's some kind of configurable that's at work here.
Of course, the first thing I did was verify that the Preferences/Locations was set to Build Location = Unique. I confirmed this both in the GUI and by popping open the .plist to check the value of IDEBuildLocationStyle and it was set to Unique.
I tried removing my existing configuration files (everthing in ~/Library/Preferences/ named Xcode) and that succeeded in changing the behavior to putting the output in the build directory of the project itself (really not helpful in my world as I have complex multi-project workspaces). Quitting and checking the settings, they were set for IDEBuildLocationStyle=Unique.
So, I copied the working configuration from another machine I had to this one. Since it too had previously had the /Development/Products destination, but had subsequently been moved to the Unique build style, I expected that to work. It did not. It instead returned the output to /Development/Products.
Thinking it might be something with my Xcode install, I created a new user and built from the same source tree (not a duplicate, not a copy, the exact same files). In this case, the output went to the right place (unique subdirectory of the Derived Products for that user). So, I blew away the ~/Preferences/*Xcode* again and copied in the preferences from the new user. Unfortunately, this took us back to the same behavior that the uninitialized configuration had, which is to say building in the build directory of the project itself.
I restored to my backup configuration files, and now I'm back to working at /Development/Products, but this isn't a good long term solution.
When checking the script output for a test script, I can clearly see that somebody is setting SYMROOT to /Development/Products in the case of the older config, and build in the case of the default configuration file.
Clearly there's something here on this system that's influencing the configuration, but I cannot figure out what it is. Any assistance would be highly appreciated!
Also - When I try to use option-Clean to enable Clean Build Folder, it is never enabled, which makes a certain kind of sense, but I thought it might be another data point.
I tried the solution in Strange behavior of Xcode Build Products Path under Build Locations and that had the same result as deleting the preferences: build products as children of the project directory.
Has anyone else seen such a problem? Have you found a solution?
Well, after a very long time of suffering through this on my laptop, I was finally able to track down the problem.
Inside of:
project.xcworkspace/xcuserdata/<user>.xcuserdatad/
there is a WorkspaceSettings.xcsettings file.
It contained a key BuildLocationStyle, which was set to UseTargetSettings.
Deleting the file and thus resetting this value allowed me to get both the Clean Build Folder... working and to get my project building correctly.
Hopefully this will help somebody else.
I created an xcode project with the same name and I accidentally overwrote the old project. How do I get it back? All old source is gone and it isn't in the Trash. It has all been replaced with the new project template code.
If you have backups/source control, you can re-sync your old version.
Back up/shelve what you have now, and leave it checked out/on your system. Then, try to replace just the project file(s), leaving your source code and data in-place. Re-do the changes to your project(s), and you will have undone the damage.
If you don't have source control or backups, and you didn't delete your code/data, you may still be in luck. You'll have to re-create your project files from scratch, rather than your last save point, but you can simply import your existing code.
If you don't have any of those, and you deleted the source, then you are out of luck
No matter what, your next step is to get and use source control and/or start doing automatic backups of your code. Everyone makes mistakes like this, and this is why source control/backups exist. You must use them.
From the other discussion, it sounds like your best hope might be an OS X undelete utility, one example:
http://www.prosofteng.com/products/data_rescue.php
I hope you've not been doing much with the drive though as any file, email, or anything else you've saved to disk could have been overwriting what used to be there. But, it's better than doing nothing.
I would boot off a separate drive before you downloaded that to run it.