For the last 2 days I've been trying to make my single-file document into a package, but I can't get it to work. In the documentation it states the preferred way is to use NSFileWrapper. I've tried it but it's just such a unintuitive way of handling files.
I guess to update a file I need to delete the file wrapper from it's directory, create a completely new one and add it again to the directory. I haven't found anything that explicitly states it, but I guess I should update the file only when fileWrapperOfType:error: is called.
As NSFileWrapper keeps everything (at least once loaded) in memory, this means that I'll have the old version and the new version at the same time until the user (or autosave) saves the file.
It seems like NSFileWrapper shouldn't be used for big files, but I think it's better if all the files that are needed by the document are inside the package(can be copied to another Mac/iPhone/iPad without errors) and I don't want to limit the user on how many/how big the files can be.
When using a manual URL-based saving mechanism, I end up getting corrupt packages, as the destination directory is always a temporary one, and I couldn't find any information on how to merge them. Every time I manually save the document without any changes, an error occurs, as I don't write anything to the temporary directory. But I don't see a reason in writing/linking everything to the temporary directory, only for it to be copied/'un'-linked back to its destination.
As I can't seem to find the right answer, what is the best-practice for saving and restoring big packages with many/big files in them?
Related
So the images below were originally a vb files. I have just opened it and it looks like this and the compiler won't run it. I am unsure whether this is a compiler error or whether it may have become corrupt because the project is stored on an external drive. It is just these two forms that have broken like this; I have one other form and a module in the same project that are okay but the project can't run because of the two that are broke.
Broken Login Form
Broken Diary Form
If it changes anything, the designer files for the forms are intact it is just the scripting for the forms elements that is broken.
Also, if I can't identify the cause, is there a way to revert it back to the last working version in visual studio to get my code back? Just because I put a lot of time into it.
The data in those files is most likely gone.
IMPORTANT: Do not write anything to that disk drive unless you find that you cannot recover those files.
If you are using a version control system then you can revert to an earlier version.
If you are using Windows 10 and you happen to have stored those files in a location included in what File History saves, you can recover them from that.
If you use some other form of backup, retrieve the files from that.
If you have a separate disk drive with at least as much free space as the one with the corrupted files, you could try running file recovery software as it might be that the zeroed-out file was written to a different place on the HDD.
TinTnMn pointed out in a comment that if you previously compiled the code, you should have executable files in the "obj" and "bin" folders that can be decompiled to recover most of your work
It could be quicker to re-write the code while it is still fresh in your mind.
when writing a file using NSFileCoordinator i need to specify the correct NSFileCoordinatorWritingOptions. Although they are explained in detail, I am not sure when to use which one. The available options are:
NSFileCoordinatorWritingForDeleting
NSFileCoordinatorWritingForReplacing
NSFileCoordinatorWritingForMoving
NSFileCoordinatorWritingForMerging
For example, what option is the correct one if I want to create a file (a plist for example)?
Wich one when I modify a file?
Can someone explain the NSFileCoordinatorWritingOptions for a better understanding?
I agree, documentation is not complete on that front, and hard to understand. And no sample code is available even for basic operations like these.
I try to think of these options in the perspective of other apps that have that specific file open, that helps getting the whole picture.
Pass no option (0) to simply update the file and notify others of your changes.
Let's say you are deleting a file that TextEdit currently displays, by providing the NSFileCoordinatorWritingForDeleting option, you're telling TextEdit to close the file as it does not exist anymore (or it could propose to save it to another place if it's in memory). It acts because of deletion.
If you're overwriting a file (as opposed to updating a file), you want about that same behavior for other apps. That's NSFileCoordinatorWritingForReplacing.
NSFileCoordinatorWritingForMoving says other apps to track the file to it's new location, so that it can be later updated.
NSFileCoordinatorWritingForMerging asks other processes to first commit their changes so that you can then merge your own changes with those.
To answer your question, you should use NSFileCoordinatorWritingForReplacing when creating a new file (even when no file exists, as it was to appear in the mean time from another app, you'd be replacing it with your own, unrelated contents). And NSFileCoordinatorWritingForMerging should be used when updating an existing file with new data, as it allows integrating the latest changes to that file immediately (instead of doing later with conflict resolution).
I'm working on an application that generates a set of bitmaps and then loads them into a form for a user to pick from.
The bitmaps are generated from a small vector library which the user can add to. The code now creates the files and then deletes them immediatelyafter use, only to have to generate them again (making the UI take seconds to load) next time the user opens the UI.
So what I'm wondering is, is it okay to leave my bitmaps in the user temp folder "forever", and regenerate them if they are not in the folder? I can't expect to be able to store the images in the application directory, due to possible permission issues, and like I said, I can't prepopulate the files since the user can add more.
Ideally you should generate any temporary data into the RAM rather to the file system.
It is acceptable to depend on temporary files if you can make sure that your application is storing only a limited amount of such files per user. Any temporary files can be left behind on unexpected crashes/power offs no matter what your code does. You therefore need to implement a mechanism that will delete any stale files created by the same application in a previous session - presumably during its next start up.
Assuming such a safety mechanism, intentionally leaving behind temporary files when the application exits sounds like a non-standard but reasonable "cache".
Caveat: the next version of your application may need a slightly different file format, and should detect, delete and regenerate any files in a mismatched format based on some simple versioning scheme to avoid cross-build dependences.
I'm updating some legacy code to more efficiently use .ini files for parameter storage. Basically, it caches all the settings internally once they're read so that they can be read again without opening the file. Before using the cache, I compare the cache creation time to the last modified time of the file, and recreate the cache with the updated file. This works great, except when users rename files, because that action doesn't update the last modified time.
So if I copy my app.ini to app - copy.ini, modify app - copy.ini outside of my program, then delete app.ini and rename the copy to app.ini, my program is now using an outdated cache. Even if my program caught the deletion of app.ini and cleared the cache, it would not rebuild the cache when the copy was renamed. The program is designed to run for a very long time unattended, so I would like to avoid continually monitoring the file - only check it once I need to read a parameter.
What you are needing is a filewatcher for vb6, you could try it by interop with .net or use something like this VB6 Implementation
For that scenario, you could keep a hash of the contents of each .ini file the program is using and periodically check each file. If the hash is different than what it was last time you checked, then it's contents were changed or it's a different file caused by this rename scenario.
We have a StarTeam view that has two files that are in the "Unknown" state – does anyone understand why they are in this state and/or how we can get them out of the state?
Is deleting them and re-adding them with a different name the only solution?
Note that if you check out these two files (regularly or using “force checkout”), they will always be listed as “Unknown” (annoying).
Thanks.
More info based on Craig's suggestions below:
a) Calculating file status using MD5 checksum: same results ("Unknown" status)
b) These two files in question have only one revision on the server. I'm not sure if this is because our CM group attempted to fix the issue by deleting and recreating the files or if there really was just one revision. The files are text files.
c) I tried deleting the files on my local machine and refreshing the status. When I do this, instead of seeing the two files listed as "Unknown", I see a total of four files listed with a status of "Missing". There are two entries listed for each file - each pair has the same file name, folder path, "modified by", and "file stamp at time of check in". I have no idea why each file is listed twice. If I select each entry in a pair and select "Compare Contents", my diff tool says they are identical.
I have this same weird issue with the four files whether I use the MD5 checksum compare or non MD5.
If I try to checkout all four of the Missing files, I get two alerts prompting me to merge the files. I say no, the files are now on my local file system and the status is back to where I started - two files listed as "Unknown".
Craig's update:
You're definitely on to something. I moved each of the duplicate items to another directory. That immediately solved the issue in that I now could checkout the four items (two in same dir and two in new dir) without any "Unknown" items. I then deleted the two items that I moved to the new directory.
In doing this, I saw some more info. We somehow have a directory structure like this:
Parent_Dir
--SubDir1
--SubDir1
--SubDir1
--SubDir1 <- Two items were here
--SubDir1 <- Two items were here
--SubDir2
--SubDir3
--SubDir4
--SubDir5
Somehow we have five sub directories with the same name and these two files in question existed in two of the sub dirs with the same name.
The issue appears to be resolved. Do you think I should manually delete the extra sub directories?
Thanks to Craig this issue appears resolved. I have no idea how this situation was created (anyone?) but.. we're good now. Thanks Craig!
It would be a huge mistake to delete the files before you determine where the problem lies. Deleting and re-adding the file would kill the history and any links to the file. It also might not fix the problem, due to the way that StarTeam works internally (with a Native-II repository, anyway). Deleting the file and re-adding the identical file will not actually update anything in the repository, except the pointers to that revision. The revision itself would have stayed there when you deleted the file, and re-adding it would just create a new pointer to that revision.
If you haven't done so already, I strongly recommend telling StarTeam to calculate the file status using an MD5 checksum. Do this in the client via Tools->Personal Options->File->Use file checksums to calculate status. Then try update status again. This is not the default setting (in at least some versions of StarTeam), so it's worth checking. If you have not already done this, it may, by itself, fix the problem.
The first thing to do is to determine if the revision is valid on the server. If the files are text, the easiest way to do that is to compare contents between that revision and the previous revision. If it does turn out that the revision is corrupt, then the best solution would be to check out an earlier revision, and then force check in. This way you preserve the history of the file.
If the file appears to be OK on the server, then test it locally, by comparing contents. If the file is corrupt locally, do feel free to delete the file locally and then check it out again. Unlike deleting the file on the server, you don't lose anything by doing this, except local revisions.
If these suggestions do not fix the problem, I still would not recommend deleting the files on the server. Tell me the results of your investigations back here, and we'll see where we can go from there. It is, in my opinion, nearly always mistake to kill history.
Update
Based on the updated information in the post, I'm getting a better sense of what is going on here. It is likely that there are two items which point to the same file, and have the same name. "Item" is a concept in StarTeam related to the fact that a single file, change request, requirement, etc. can live in multiple places at once. For example, you can have a single file in two different views or projects.
Generally, you do not have the items with the same name in the same folder. But it can happen. And that probably explains the "Unknown" status. When you tell StarTeam to compare the file on disk with the item of the same name on the server, perhaps it can't figure out which item it should look at.
The first thing I would try is to try and drag one of the two items somewhere else. If that fixes the problem in the folder in question, you can delete the item elsewhere, without affecting the item in the folder. If, on the other hand, dragging one of the items elsewhere causes them both to move, it's easy to drag the item(s) back to where they came from.
Update 2
Do you think I should manually delete the extra sub directories?
Yes, but just as with the files, move them first, and make sure the subdirectories you'd like to keep are unaffected before deleting them.
A good way to identify this issue if it comes up again is to click on the root folder, add folder path to the shown columns, then click the all descendants button. Sort the files by name, and look for the unknown files and see if multiple files of the same name are checking out to the same path. Usually this is the result of a mistaken share, addition, or a change in folder check-out path.
As it is undetermined what order StarTeam will check files out, having two different files with the same name pointing to the same local location is a mistake. The 2005R2 native Windows client and Cross Platform client would pull files in a slightly different order, causing views with this issue to produce checkouts with different files.
There are a few ways to legitimately end up with this situation - keeping multiple branches of a single file on the tip and designating which to use by view label is a common one. StarTeam is one of the few VCs that can handle multiple references like this.
Separately, if you can help it, never delete and re-add a file. 99% of the time, it isn't what you want to do. Re-adding a file to the server gives it a whole new archive in the database and it will not be tied in any way to existing shares of that file. You will also lose all of your revision history. Instead, look for ways to move files. And if you have multiple files with the same name and content on your server, it is usually a good idea to make an effort to share the file to the various places it should exist rather than re-add it. This will make sure your changes propagate so you don't need to check-in fixes multiple times.
Were those files added twice? You can add the same file multiple times which could result in this error. Also, check the Reference tab - are these linked files to elsewhere in the repository?
Could that be the files or their status got corrupted on the server? In that case, delete and re-add is the only way.