I created a data model file "ChatModel.xcdatamodeld" in my project. Then I merged branches on github. There're conflicts in "project.pbxproj". I fixed them. Then the error happened:
"/Users/mac/zhongqing-ios/Zhongqing/Zhongqing/Model/ChatModel.xcdatamodeld: Could not create bundle folder for versioned model at '/Users/mac/Library/Developer/Xcode/DerivedData/Zhongqing-chngcirectbawjenegkxtgdfgoux/Build/Products/Debug-iphonesimulator/Zhongqing.app/ChatModel.momd'".
"/Users/mac/zhongqing-ios/Zhongqing/ChatModel.xcdatamodeld: Unable to write VersionInfo.plist for versioned model at '/Users/mac/Library/Developer/Xcode/DerivedData/Zhongqing-chngcirectbawjenegkxtgdfgoux/Build/Products/Debug-iphonesimulator/Zhongqing.app/ChatModel.momd'".
Each time I have to delete the Derived Data so that the project can be run.
And then the error happen again.
Although some files are readable they should be treated like binary files. .pbxprojfiles are good example.
From pro-git
Some files look like text files but for all intents and purposes are to be treated as binary data. For instance, Xcode projects on the Mac contain a file that ends in .pbxproj, which is basically a JSON (plain text javascript data format) dataset written out to disk by the IDE that records your build settings and so on. Although it’s technically a text file, because it’s all ASCII, you don’t want to treat it as such because it’s really a lightweight database — you can’t merge the contents if two people changed it, and diffs generally aren’t helpful. The file is meant to be consumed by a machine. In essence, you want to treat it like a binary file.
Related
the app where I am working on was audited and the security team has a concern that consists in: so, for some reason if I extract the .ipa's payload I am able to identify which CI/CD tool was used to generate it. For example:
Terminal:
cd MyApp.app <- payload
strings * > ~/Desktop/file.txt
Inside the file I can find that we are using jenkins
/Volumes/jenkins-workspace/MyApp-Generic/MyApp/MyApp/SomeViewModel.swift
Has anyone faced this problem (if we can call it a problem)? Is there a way to obfuscate or completely remove this kind of references from the IPA?
Thanks
Does that file have a fatalError() call in it? If so, the file and line number will be reported when it runs. Here's a way to fix that if you really need the fatalError call.
If any of your source files have #file compiler directives in them, they will record the path to the file in the executable.
Swift 5.3 introduces a #fileID identifier which produces a shorter
string than #file. The #fileID string contains the filename and module
name, but leaves out the rest of the path to the file; this saves
space, improves performance, and avoids accidentally embedding private
information like the developer’s home directory name in binaries.
Compiler-generated error messages (like force-unwraps) and standard
library assertions like precondition and fatalError now use #fileID
strings, and we recommend you use them instead of #file in production
code. (SE-0285, 65514304)
This pretty much sums my problem. I am using the #file identifier in some methods (mostly for logs) and every file that calls that methods will appear embedded in the app binary.
Ref: https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes
How can I change a file type?
A year ago I wrote a few articles that should be viewed in any text type of program. however, I recently opened them and they are viewed in symbols and alphanumeric characters. In linux os, the 'file' is now in an archived folder type that contains .xml files. in windows os it is 'file' as type of file. it has no extension.
Is there any way to recover the original readable alpha-numeric information in these files?
My preference would be to salvage the original information than redo.
First off the extension doesn't actually mean anything for the information of the file, it's only purpose is as a hint to the OS for deciding which application should be used in opening the file. You can prove this by renaming something like an exe to have a txt extension which will then open in notepad as a lot of seemingly random characters; renaming it back to exe will allow it to run again.
Based on your description the files you mention are some form of binary file, the bad news with that is you need to know either what application was used to create the file in order to be able to open it or what the original file extension was (which would be a hint to the former).
If you don't know either of those pieces of information you can of course use trial and error by guessing what extension it might be, renaming it, then opening it with the associated application and seeing if it worked.
I have a corrupted 7-zip archive that I am extracting manually using the method outlined by Igor Pavlov at this link. An intermediate result is a large file that is a bunch of files cat'ed together that must be separated manually. I understand that some file formats will need to be extracted manually by a human using discretion (text files, etc.) but many file formats encode the size of the file as part of the file itself (e.g. .zip). Furthermore, some files can be parsed and their size can be deduced with just a little information about the file format (e.g. .pdf). Let's say the large file consists of the following files concatenated together:
Key: <filename>(<contents>)
badfile(aaaaaaaaaaabbbbbbbbbcccccccdddddddd) -> zip1.zip(aaaaaaaaaaa)
badfile2(bbbbbbbbbcccccccdddddddd)
I am looking for a program that I can run on a large file (call it badfile) that can determine the type and size of the first logical file (let's say it's a .zip file) contained within and create a new file to hold the contents (e.g. zip1.zip since filenames are lost) and chop the file off the front of badfile. This would allow me to run the program in a loop to extract files with known types and/or pause and let the user handle the difficult cases. Does such a program exist? I know that the *nix command file(1) will do a lot of the work here, but there would be a lot of effort in encoding rules for sizing files (e.g. .pdf) that I would prefer to not duplicate.
I believe this question should be closed due to being off topic as it asks to find existing programs to solve the problem, but open bounty prevents close vote. However.
Does such a program exist?
Yes they exist is and are called data carving tools.
Some commom ones include scalpel and foremost and PhotoRec
A list of other tools is avaliable here
I'm using CoreData for one of my databases, and I'm having trouble with an upgrade to my App.
My old databases are no longer loading ... I get the error "Cocoa error 134190" which I believe means that the inferred mapping model is failing.
When I started editing this version of my App, I created a new model version, and I simply added one new attribute to one entity, and two new attributes to another entity. Nothing was changed or deleted.
I've checked inside my App's directory, and all of the model versions are there.
I even have a snapshot of my previous version of the App, and with that snapshot I can load my core data files.
To debug what is going wrong, I took the exact data model from my previous snapshot and used it in my current version, and I still get the error.
I've even done a "diff" on every file in my ".app" directory packages, and there are only two files that are different between the two. One is the actual binary for the application, and the other is the "Info.plist" file. I looked at the Info.plist files, and they too are basically identical (the new one has a newer bundle version, but no other change).
Any idea why the inferred mapping is broken?
I am getting the same error even when the data models are completely unchanged from my last version which works.
This is extremely frustrating.
Any information as to how to track down problems like this in the future would also be greatly appreciated!!!
I found the answer ... the problem was that in my new version, I was rearranging the locations of my files. I did so by simply moving the database to a new location. What I didn't realize is that coredata databases have some knowledge of their path built in, and you can't simply move them.
I needed to change the location of the database using the NSPersistentStoreCoordinator's method:
migratePersistentStore:toURL:options:withType:error:
My fault, but I really wish that core data error messages weren't so cryptic.
In the next version of my App, I'm going to remove core data completely.
Ron
I don't believe core data actually cares where the database file is, but I could be wrong. In the times I have seen this error, specifically "Cocoa error 134190" while trying to infer a model mapping, it's been the case that there was actually a problem trying to migrate to the next version of the model.
For example, when I found this thread today because I was helping someone with this problem, the real underlying issue was that the type of one of the attributes was accidentally changed. The automatic migration can't handle that sort of change.
A somewhat easy way to look at the changes between two model versions is to diff the description files themselves on the command line with diff:
diff yourNameHere.xcdatamodeld/yourNameHere5.xcdatamodel/contents yourNameHere.xcdatamodeld/yourNameHere4.xcdatamodel/contents
(That assumes you have a core data model description named "yourNameHere" and you're looking at a problem migrating from version 4 to 5. You'll have to adjust for your specific files.) In this diff you should see whatever additional things you've added, but you're really looking for something like a type changing when it shouldn't.
I created one project with core data that will work with unchangeable database. And I don't want to write code in this project , that will programmatically populate this database. So, I create second project with core data, add existing xcdatamodel from first project without copying(only references). There i populate my database, open it with mozilla plug-in and it successfully filled. Then I copy ,my *.sqlite file and manually replace it with old file in first project. It causes error:"The model used to open the store is incompatible with the one used to create the store". But I use for both files the same xcdatamodelid. Where my error?
Sorry for my english, I really need help.
P.S. when I open sqlite file from first project and second (with commented code of populate base) in FileMerge - second is already empty. I appreciate any advice or help.
Karoly S nicely answers the question. I have a hint that I frequently employ that may prevent this out of sync situation. Instead of two Xcode projects trying to share one model file, just create one Xcode project with two targets. Each target will use the same model file, any class definitions derived from that model, and possibly other code. My second target is a Mac OS command line program that generates the database, while my first target continues to be the iOS app that reads that database. The Mac OS target will overwrite the database file in a project subdirectory, ensuring it's up-to-date. If I make any changes to the model, Xcode knows to update both targets.
Did you change your Model Definitions in any way? The error you are seeing is because there is some difference between the model from when you created it, and again from when you are trying to reference it. Are you running on the simulator? Try to delete both of your apps to clear the data related to it, as it might be out of date. Afterwards simply rebuild both of your projects as that will update your core data database.
EDIT: To clarify a bit more, your core data model is out of sync, this is generally caused by you building and running an app, and a database being created, then redefining your object model, this can be done in a variety of ways, most likely caused by the addition of an attribute or entity. So when you are trying to load the database there are fields that the app and core data are looking for, but are not there because they did not exist when the database was created. I hope this helps.