Xcode appears to save files atomically when you save. This seems best practice but when you are listening for file changes atomic saves can dodge a kevent file status change. Im using a library called vdkqueue that listens for file changes. This will work successfully when a make a save on the target file using textedit and sublime text. However when I save this file using xcode the notifcation will not fire. This is due to xcode making atomic saves so a temp file is made on save and the link to the file is lost. Is there any way of disabling atomic save in xcode, or even a mac wide setting would suffice.
If you are observing a file, that might not work (because the file you are observing is never actually modified). Observing the containing directory should work reliably.
Related
I'm trying to implement a file explorer that will display a list of remote files(stored on another network server). And I use QFileIconProvider.icon(QFileInfo) to get the file icon.
The QFileInfo is constructed from a single filename(no path information):
for example: QFileInfo fi("test.jpg");
and that works on both Windows and Linux(I tested it on a Ubuntu machine), but it doesn't work on the macOS. On macOS, I always get the warning
Path given to -[NSWorkspace iconForFile:] is not a full path.
I have checked the solution here: Qt 4.8 - QFileIconProvider, Getting icon for non-existent file (based on extension), but it's for the Windows platform.
I was able to make it work if I created a temporary file on my working directory with the same remote filename. But the temporary needs to be kept. If I deleted the temporary file after calling QFileIconProvider::Icon, I will get the warning above when the QTableView tries to display the QIcon in the UI.
Is there any working solution for my case?
Thanks all.
Since there is no "correctly" solution, I just make a workaround:
Create a temporary file for each file extension, and keep them here, only delete these temporary files when you ensure you don't need them anymore. (I choose to delete them before my app quit.
At least, it works for me.
Thanks!
I recently converted my OS X app to use a package-based file format instead of a single-file one. My document class is a sub-class of NSDocument, and I'm using the -fileWrapperOfType: to generate the file wrapper for writing and letting the framework do the write to disk. (In other words, I'm not using any of the write methods from NSFileWrapper itself.)
I'm running 10.9.4, Xcode 5.1.1, 10.9 SDK.
I am able to read and write the file OK, and if I make changes to the document they do get properly written out to the file package. I can see the changes when I examine the file package contents from the terminal, and the changes are present as expected when I read the file back in.
However, the changes do not appear in the Finder when I examine the package contents using the "Show Package Contents" command.
Do I need to do something to get the Finder to recognize the changes to the package contents?
Thank you for any advice or ideas on this one!
Currently, I am using the ruby Listen gem that listens for file saves in an ongoing manner and then my application can reacts accordingly after a file is saved. What I would like to do is be able to be updated if a user is updating a file, but not rely on save to get that information.
The use case would be that User X opens a .txt file (which I have predefined) and starts typing in it. With every cursor move, change, keystroke etc I can hear that something has changed and be able to know what the current contents of that .txt file are.
Any thoughts?
Since most editors read the file to memory, and let the user edit it there, the file system has no idea whether any editor is currently editing any file in memory...
The only thing the file system 'knows' is when a file is read or written...
I have an OS X app that relies on NSPersistentDocument and Core Data to handle the app's custom file type (which is being saved as XML).
I've noticed that when I update my Core Data model (I'm making simple changes, relying on lightweight migration) simply opening a file with the app that's utilizing the new model will change the file on disk. A backup version of the original file also appears on disk (with a '~' appended to the file name). Once this happens, it's impossible for the previous (released) version of the app to open the file.
To be clear: I'm simply opening the file. I am not saving the file back to disk. I can watch in the Finder and see the '~' appear as soon as I open a file.
This seems like really dangerous behavior. I have to be very cautious and not ever open a file that's currently in use by my user base because doing so will instantly make it inaccessible to them.
Is this default OS X behavior? Is there a way to configure NSPersistentDocument or my Core Data model so that opening a file changes the store internally to the app but the changes don't get propagated back to disk unless I explicitly save?
Core Data seems to assume that if you're opening an old file with a new program, you must want to go ahead with migration. From my own experience, it is default behaviour that when the file is opened, it is automatically migrated and can no longer be opened with the previous version program. I believe it has to do with the hash numbers, which must be changed to allow the new store to open the file, making it a permanent change in the document; so no, I don't think you can open the file, but not propagate the changes back to disk. Perhaps you could override a method that would allow you to make a copy before starting migration.
Apple's Developer Library mentions the temp files that are made:
If the migration proceeds successfully, the existing store at storeURL
is renamed with a “~” suffix before any file extension and the
migrated store saved to storeURL.
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreDataVersioning/Articles/vmInitiating.html#//apple_ref/doc/uid/TP40004399-CH7-SW1
I'm in the middle of putting together a script that manipulates an OmniGraffle document and saves the result of each progressive manipulation as a PNG. That's all working fine, but at the end of process, I want to close the file without saving the changes.
Naturally, I reached for the "revert" command. Except that "revert" doesn't appear to be a command on Lion. I tried "close saving no," but since it was autosaving as each manipulation was made, that didn't work.
Of course, I can simply leave the document open and manually revert it. Nevertheless....
Am I missing something? Is there truly no way to programmatically roll back changes made to a file using AppleScript on Lion?
Update: it appears to be worse than I expected — on a volume without permanent version storage, at least — after many manipulations with AppleScript, "Revert Document…" was no longer even available in the File menu.
I can only think of a workaround: since you're not interested in keeping those intermediate versions anyway, you could:
make a backup copy of the file prior to opening it in OmniGraffle
do your changes + PNG exports
close w/o saving
overwrite the file with the backup copy (and delete the backup)