How to save a read-only file in Geany? - geany

When edit a read-only file by Geany, I can't save the file.
Is there some plug-in support to change the file's mode then save it?
Thanks!

You might could use the save as function as save it under new name + rename the old one. Change permissions is not yet supported.

Related

how to see where and what the changes are when file is modified externally

i modify file externally (see below), i want to know where and what the changes are in emEditor,
how to do ?
thanks!
You can use the ActiveCompare macro, written by Takahiro Kawakami.
When the File changed by another program. Reload with changes? message box appears, select Don't Reload, and run this macro. You will be able to compare the current document with the file on disk.

What is the difference between mozconfig vs moz.configure?

I'm trying to build firefox.
it says to edit my mozconfig file. I see a moz.configure file, but no mozconfig file. Should I edit the moz.configure file or create a mozconfig file?
You should not be changing the moz.configure file, as this is a configuration file used internally by the mach build system.
Instead, you should create your own .mozconfig file (don't forget the initial dot!) and put your customization options in there. Simply touch .mozconfig to create the file, then edit it. A brief overview of that file is available on MDN.

Why does .MSI file open read-only?

I am attempting to open a .MSI installer package file to modify it. Whenever I try to open it, it opens in read-only mode. I see this with Orca, with InstEd, or when opening the file directly via code:
`MsiOpenDatabase()` (ERROR_OPEN_FAILED with MSIDBOPEN_DIRECT or
MSIDBOPEN_TRANSACT persistence modes).
The file itself does not have the read-only attribute set (in fact, has no attributes set)
I am using an account with Administrators group access
As far as I can tell, no other process has the file open
No installs are in progress or suspended
I can copy the file to another location, and open it read/write there. But the original, I cannot touch
Thanks in advance for your help.
My guess is that this is caused by one of the following factors:
Custom NTFS access rights - defined for the file in its security descriptor
The file might be "blocked" - marked with a special flag after being downloaded via Internet Explorer.
The resolution for the latter is to right click the file and select properties and click the unblock button at the bottom of the property page and pressing OK.
The resolution for custom NTFS rights are done in a similar way by going into the security
tab of the property page for the file, but it is easier just to copy and paste the file and use the fresh copy with the default security.
Found it.
#Glytzhkof, you almost had it but there's a detail I did not know about, and left out. This is a package that lies in a folder under "access protection" by my system's anti-virus program: a filesystem hook that blocks modification of critical system and AV files. Turn off access protection temporarily, and the file is wide open.
Fortunately, one of my teammates had some experience with this, and suggested I try it. Bingo.
Thanks, all.
What I have done to get it working was to create first a backup of the MSI file, and then open that backup. It worked for me
Try to close/kill processes that might interfere, for example:
Other running Install shield instances
Installshield updater
Installshield licensing service
Antivirus

Is there a way to listen for non-saved changes of a file?

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...

File changes on disk when opened by app with updated Core Data model

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

Resources