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...
Related
I'd like to download a CSV file from JupyterLab.
It's 66MB and it shows the file is downloading, but it's split into CSV and CSV.part.
According to JupyterLab, the download has finished but they haven't combined into a single CSV.
When I open the csv.part, it says there are no applications to open it.
When I open the csv, it's empty.
I've tried re-downloading and it's always the same.
What do I do here?
Whatever application you used to download the file - a web browser? Safari? Chrome? - downloads the data into a temporary file (with .part on the end) and it is supposed to rename it to myfile.csv after the download has completed.
For whatever reason, it has not done this last step.
Simply delete the empty file myfile.csv and rename myfile.csv.part to myfile.csv. You will see a warning ("Are you sure you want to rename this?") - yes. You are sure.
There is nothing magical about file name extensions, except of course that they tell MacOS which application to open the file with. They should also give you a clear indication of what sort of data is in the file, but this is not actually enforced by anything. If you rename a file to something inappropriate for the content (e.g. if you name your file "myfile.mp3"), it simply won't load into the application as the data isn't valid. But, there is nothing special about the .part file - the name is just supposed to indicate that the download (probably) hasn't finished yet. Except in this case, I assume you know that it has.
(This seems like a bug to me, perhaps with JupyterLab - but that's beside the point).
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.
As I understand it, when a file open dialog box (such as GetOpenFileName) is used, Windows will automatically remember where the last file was that was opened by the program, and Windows remembers these locations separately for each program. Is there a way to directly alter this, in order to cause the file picking dialog for program X to start in C:\Example\Directory?
I'm attempting to automate a program which has been programmed to work only through a GUI, and I don't have any access to the internals of this program (such as being able to alter how it calls the file picker). Instead, I'm using a mouse macro (via AutoHotkey). If I can be completely sure that the file picker will start in a particular place, I should be able to automate the rest with mouse clicks.
If you had access to the source code, I'd suggest you just change the lpstrInitialDir property of the OPENFILENAME passed to GetOpenFileName().
Outside of that, you'll want to change the registry keys for the MRUs:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
What might make more sense, and might fix the issue you're having, is also changing the Working Directory so that the default location isn't "My Documents", if you're experiencing that.
Depending on the operating system, the results vary:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx
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
This is only under windows env.
As I know windows os identifies associated application of a particular file by file extension.
Like wise each file (binary) starting with corresponding symbols ("starting symbols"). For an example .JPG starts with ÿØÿà. Let say I open this .JPG file in a Hex editor or a Text editor and then I change that starting symbols into another file type. for an example I can change ÿØÿà to .Eߣ (.mkv). So when I double click on the .JPG the Windows Photo Viewer says there are some errors or similar message. So I need to get some information about the application that tries to open that kind of a file. If I can, I need to open that file using the application that associated with "starting symbols".
Briefly when I open .JPG I need to open a default video player .mkv files. But It may not work for this example. Because I changed only the "starting symbols" of my .JPG.
Please give me any idea to do this.
Thanks!
When you encrypt the file, give it a new extension. e.g. Picture.jpg becomes Picture.encrypted-jpg. You then register as the handler for encrypted-jpg, decrypt the file, then launch the normal jpg handler.
When the shell is asked to perform a verb on a file, the shell does not use the contents of the file to determine which app to pass it to. The file extension is what determines how the file will be treated.
You wish to use the contents of the file to influence which app processes a shell verb. In order to do so you would need to create a launcher app that reads the file header and then decides which app to pass the file on to. You would assign your launcher app as the handler app for all file extensions that you were interested in.
Although you could do this, it would be much easier just to set the file extension appropriately.
The proper way to do this sort of thing is to replace the files with reparse points.
The downside is that this involves writing a file system filter driver, i.e., an operating system extension, which is a whole level of trouble above and beyond ordinary application programming. (Since Windows already does file encryption, I doubt it would be worth the effort.)