I have written a custom external file handler (EXTFH), but there are some cases where I want to revert to the Micro Focus EXTFH. The cases are on a file by file basis (as opposed to a filetype by filetype basis).
My idea is that upon OPEN, I place a marker in the FCD that tells the subsequent operations (READ, WRITE, CLOSE) as to which EXTFH is in use.
My EXTFH has control and the logic can be very simple if there is a place in the FCD that is guaranteed to not be corrupted by MicroFocus.
Is there a place in the FCD (fcd2.h and fcd3.h) that I can mark an open file as being opened by my EXTFH?
My worst case is that I keep a list of the fcd->handle pointers that I have allocated and if I allocated it, then direct to my EXTFH. If not, direct to the MF EXTFH.
Here is the documentation from Micro Focus on EXTFH:
http://supportline.microfocus.com/documentation/books/sx20books/fhexfh.htm
That is older documentation, but is appears to be pretty much up-to-date.
[edit to clarify how we will use detect which to use: We will use the extension on the file name to determine which file handler to use. For instance, if the extension is: .xyz, then use our EXTFH, otherwise use MF EXTFH]. It appears we can check the filename on every fileio, but I think it would be cleaner if we just checked upon OPEN. For subsequent calls for that file, we would just check something in the FCD.
Related
I am implementing a HDF5 layer in an interpreted language with automatic reclamation facilities (garbage collect).
When a proxy to a HDF5 entity (H5File, H5Group, H5Dataset, H5Dataspace, H5Datatype, etc...) will be no longer referenced, it will be automatically reclaimed. With ephemeron like facility, I can arrange to be noticed and invoke the corresponding close function automagically (H5Fclose, H5Gclose, H5Dclose, etc...) in order to release the target resource.
By default, I have no control on the order of reclamation. However, if ever order of close counts, then I can arrange to keep a strong pointer on a parent proxy (for example the H5 File) from within any other entity. If order does not count, then I will avoid this useless complication.
So my questions:
Can I invoke H5Fclose(fid); before H5Gclose(gid); where previously gid=H5Gcreate(fid,'/foo',H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT);?
Can I continue to operate on the group once I closed the containing file? For example, is it legal to call H5Fclose(fid); before gid2=H5Gcreate(gid,'bar',H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT); in above example? If not, are there other entities concerned, or is it just file?
Doh, case of blindness, the documentation tells that close is delayed until all objects have been closed, so 1. order does not count and 2. is legal.
https://support.hdfgroup.org/HDF5/doc1.6/RM_H5F.html#File-Close
However, it may not work in every circumstances, so it's not recommended.
H5Fclose terminates access to an HDF5 file by flushing all data to storage and terminating access to the file through file_id.
If this is the last file identifier open for the file and no other access identifier is open (e.g., a dataset identifier, group identifier, or shared datatype identifier), the file will be fully closed and access will end.
Delayed close:
Note the following deviation from the above-described behavior. If H5Fclose is called for a file but one or more objects within the file remain open, those objects will remain accessible until they are individually closed. Thus, if the dataset data_sample is open when H5Fclose is called for the file containing it, data_sample will remain open and accessible (including writable) until it is explicitely closed. The file will be automatically closed once all objects in the file have been closed.
Be warned, however, that there are circumstances where it is not possible to delay closing a file. For example, an MPI-IO file close is a collective call; all of the processes that opened the file must close it collectively. The file cannot be closed at some time in the future by each process in an independent fashion. Another example is that an application using an AFS token-based file access privilage may destroy its AFS token after H5Fclose has returned successfully. This would make any future access to the file, or any object within it, illegal.
In such situations, applications must close all open objects in a file before calling H5Fclose. It is generally recommended to do so in all cases.
In my extension, I need to write a huge file (say around 20 gigs) to the disk. Currently I am doing it in the main thread, but file creation is very expensive operation. I was about to move the whole file creation process to a ChromeWorker, but based on https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers I cannot have access to the nsiFile from a ChromeWorker.
So my questions are:
1. Is it possible to access Cc, Ci, and Cu from within a ChromeWorker?
2. If not what would be the most efficient way to create and fill large files in Firefox. Note that I need to write the file based on segments and offsets (Ci.nsISeekableStream).
It's not possible to access nsIFile from ChromeWorker. But nsIFile is horrible synchronus option.
Go with OS.File: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/OSFile.jsm
On that page go to the link for usage on workers: https://developer.mozilla.org/docs/Mozilla/JavaScript_code_modules/OSFile.jsm/OS.File_for_workers
On the mainthread os.file returns promises.
In worker they are synchronus. Wrap your os.file functions in worker with a try-catch, as when an error occurs, (like os.file.remove with option of ignoreAbsent set to false) then the catch will hold the OS.File.Error object.
Great move to ChromeWorker btw! I'm a huge fan of ChromeWorkers. I wrote a simple example of jsm using chromeworker here: https://github.com/Noitidart/jpm-chromeworker
For segments, you'll have to OS.File.open and then on the return value do a .setPosition() then you can read certain number of bytes from that position, or write, or whatever. Its awesome stuff. OS.File is the new way and the recommended way to do file operations. Its been around awhile now though since like Firefox 29 or before that.
I'd like to get a file last modified time in Delphi.
Normally something like FileAge() would do the trick, only the problem is: if I overwrite *File A* with File B using CopyFile, File A's modified date is not updated with current overwrite time as it should(?)
I get that: CopyFile also copy file attributes, but I really need to get the modified date that also works when a file is overwritten.
Is there such function? My whole application relies on modification time to decide whether or not I should proceed with files!
EDIT Just to clarify: I'm only monitoring the files. It's not my application who's modifying them.
The documentation for CopyFile says:
File attributes for the existing file are copied to the new file.
Which means that you cannot use base your program on the last modified attribute of the file, or indeed any attribute of the file. Indeed there are all sorts of ways for the last modified attribute of the file to change. It can in fact go backwards in time.
Instead I suggest that you use ReadDirectoryChangesW to keep track of modifications. That will allow you to receive notifications whenever a file is modified. You can write your program in an event based manner based on the ReadDirectoryChangesW API.
If you can't use ReadDirectoryChangesW and the file attributes, then you'll have to base your decisions on the contents of the file.
I have an application and posted to Cydia recently. It has been cracked by someone else and posted it in torrent sites. I have a binary checksum verification mechanism inside and they were able to create a new checksum file based on the changes they have made to the binary. They have edited two functions and decompiled it and posted it to torrents.
I saw that it's possible to see the actual implementation of functions and classes. But in order to edit the functions they have to find the address of that function and edit it via HEX EDITOR. I don’t want to make it "unhackable", but I really want to find out how they hack.
How can I edit a function in an iOS binary and re-compile it? For example I have a following method in one of my classes.
- (id) getSomething {
return #"Something";
}
I want to edit the return value of this function. Is that possible?
Usually, you don't "re-compile" it. Just feed the file to IDA, look for strings, function calls or whatever you are looking for and then use a hex editor or similar to edit the file on assembly level. In most cases it's enough to simply change a conditional jump into an unconditional jump or a nop (no operation). If you want to change return values, you have to put a little more effort into it, but in my experience you either edit the char sequence right inside the binary file, if it's specified as a constant or initial value - or you just write a completely new function and "copy" the assembler code of it into the original file. You just have to make sure your new function does not take more space than the original - or everything's getting a lot more complex.
I hope that's what you were asking for, otherwise just tell us which app you are talking about and we can look deeper into it :)
near the top of the code i see things like,
btn_dropdown._visible = false;
mcMenuBkg._visible = false;
but I can't find these assets anywhere in the library or in any code, how does this make any sense?
The movie clips in the library that look the same have different names and I can delete them entirely and they still show up when I compile and run, or I can add trace statements into their code and they never get called.
where on earth are these assets defined?
In theory, any clip you see at runtime could be dynamically created, by making an empty MC and drawing in whatever contents you like with the drawing API. However, if you see clips in the library that are similar to what's showing up at runtime, then it's very unlikely that that's happening.
Your first step should probably be another look through the library. Remember that instance names don't have to be the same as MC names; even if something is called "Menu Holder" in the library there might be an instance of it somewhere called "mcMenuBkg" or whatever. But the fact that you can delete stuff without changing the output is mysterious.
So, other possibilities: contents are being loaded externally, or imported via runtime sharing. If feasible, try moving your SWF to a temp directory and running it from there; that should break all loads (unless contents are loaded from a remote URL).
Or, you're looking at the wrong clips in the library. If it's a crufty project there may be unused stuff in there. Try expanding the library wide enough to see the "Use count" column, and select "update use counts" from the library menu. Anything with a count of 1 or higher is part of your FLA's stage content - either it's sitting on the main stage or it's a child of something that is. Clips with a use count of 0 may still be used if they have a linkage ID; they could be created at runtime with attachMovie(). However, for any clip with a use count of 0 and no linkage id, it's safe to assume that it's unused, and irrelevant to what happens at runtime.
If none of that helps, the only things that come to mind are sanity checks... open up everything on the stage and every clip with a linkage id, and check for empty/invisible MCs. Check the Movie's export settings to make absolutely sure the SWF you're checking is the same one being published. And just for grins, open up the "Scenes" panel and make sure that some diabolical fiend hasn't put important content on a separate scene where no sane man would look for it.
Vague answer for a vague question. :D Hope it helps...
You can create movie clips with code dynamically.
This means that you may not have them in your assets if you are unable to find them.
You can create any type of symbol using a constructor out of thin air with actionscript alone.
I would search the code for one of these
var mybutton:SimpleButton=new SimpleButton();
If they're being set to
_visible = false
you won't see them anyway - and as ActionScript 1/2 doesn't do runtime error reporting, the Flash player won't complain if they're not actually there on the stage. If they're not being used, just delete them.