While browing through /proc, I am across /proc/net/fib_trie which seems to have main routing table of kernel inside it. My question is if modifying it will change the routing table or it is a stat only file?
(I want to modify routing table programmatically and I am total noob in C so looking for other options. File modification will be easy in any language)
In another question, MattSmith mentioned in a comment that modifying the file /proc/net/route and using ioctls is a solution, Can someone please guide me how?
My question is if modifying it will change the routing table or it is
a stat only file?
No, route table won't change as file is read-only.
In another question, MattSmith mentioned in a comment that modifying
the file /proc/net/route and using ioctls is a solution, Can someone
please guide me how?
From user space perspective you can use netlink sockets to manage routing table.
See some C example. However, it would be difficult for newcomer.
So the easiest way is to use ip utility(in fact it uses netlink sockets). That way, you can implement your own shell script and execute routing manipulations within it. You can search for proper usage of ip tool.
Related
Recently I've stumbled upon "If you want to use GUIDs to identify your files, then nobody's stopping you" article by Raymond Chen and wanted to implement this method. But then I found that there is another way to get file ID and this is GetFileInformationByHandleEx with FILE_INFO_BY_HANDLE_CLASS::FileIdInfo and using the FileId field (128 bit).
I tried both, both methods works as expected but I have a few questions I cannot find any answers to:
These methods return different IDs (and the id from GetFileInformationByHandleEx seems to use only the low 64 bit leaving the high part as zero). What each of them represent? Are they essentially the same thing or just two independent mechanisms to achieve the same goal?
Edit: Actually I've just found some information. So the ObjectID from DeviceIoControl is NTFS object ID but what is the other ID then? How do they relate (if at all)? Are both methods available only on NTFS or at least one of them will work on FAT16/32, exFAT, etc?
Documentation for FILE_INFO_BY_HANDLE_CLASS::FileIdInfo doesn't tell us that the ID may not exist unlike FSCTL_CREATE_OR_GET_OBJECT_ID where I need to explicitly state that I want the ID to be created if there isn't one already. Will it have any bad consequences if I'd just blindly request creation of object IDs for any file I'll be working with?
I found a comment for this question that these IDs remain unchanged if a file is moved to another volume (logical or physical). I did test only the DeviceIoControl method but they indeed don't chnage across drives but if I do move the file I'm required to supply OpenFileById with the destination volume handle, otherwise it won't open the file. So, is there a way to make OpenFileById find a file without keeping the volume reference?
I'm thinking of enumerating all connected volumes to try to open the file by ID for each until it succeed but I'm not sure how reliable is this. Could it be that there could exist two equal IDs that reference different files on different volumes?
How fast it is to ask system to get (or create) an ID? Will it hurt performance if I add the ID query to regular file enumeration procedures or I'd better to do that only on demand when I really need this?
I'm currently developping a miniFilter driver from scratch.
Right now i'm just trying to understand how all of this works, which actions leads to which IRP event etc...
After some tests with the miniSpy filter Driver, I can see those 3 Major operation and can't figure out what is done.
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION
IRP_MJ_QUERY_INFORMATION
IRP_MJ_RELEASE_FOR_SECTION_SYNCHRONIZATION
I'm usually using this link : https://msdn.microsoft.com/en-us/library/windows/hardware/ff548630(v=vs.85).aspx
But I can't found ACQUIRE/RELEASE_FOR_SECTION_SYNCHRONIZATION.
Can someone explain me what they mean ?
First of all you might want to check this out.
You can think of the IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION as callback for CreateaFileMapping. It essentially tells you that the FILE_OBJECT in question is about to have section object created for it.
IRP_MJ_QUERY_INFORMATION its the file-system callback for ZwQueryInformationFile. Check that one out for more details on various information classes and what structures are behind each buffer for each class.
IRP_MJ_RELEASE_FOR_SECTION_SYNCHRONIZATION has no parameters. Consider it as an equivalent of CloseHandle(SectionHandle). Check this.
Hope it clears things out.
Good luck.
I'm using Docpad and want to do increment a counter (for cachebusting of assets) every time a static site is generated.
I figured the easiest way would be t:
hook into docpad.coffee.writeBefore
increment a counter templateData.assetCounter
persist docpad.coffee.
Still figuring out the functionality that comes out-of-the-box with Docpad, so looking for a way to persist docpad.coffee to disk. Would that be a good idea at all?
Of course I could read/ write to disk using require('fs') but that may conflict/race with what docpad may internally be already doing (just guessing)
ideas?
That's a really cool idea! A plugin would be great for this, it could:
hook into docpadReady to load the persisting file
hook into extendTemplateData to add the current counter value to the template data
hook into writeAfter to increment the counter and save it to the persisting file
the persisting file could just be my-website/generateCounter.json
This way you don't have to modify your docpad.coffee file after each generation :)
I encountered a new term called 'NAILDUMPS' when I analysed a flowchart explaining a series of jcls.In some steps of that flowchart it is mentioned as"this file is naildumped" .Can anyone explain what is a naildump and why it is used?.
Thanks in advance
In all my travels through the mainframe world, I've never heard this term, not with Fault Analyser (or its competition) or with system abend stuff, where you'd expect to find it.
Most likely thing is that it's an application specific thing. If you could provide the context around the comment in the JCL, such as a program name like IEBGENER or IEFBR14 (with the options), it may be easier to tell you what it's doing.
For what it's worth (a), there's one page that Google serves up showing one use for this elusive program. The link states that, to empty a dataset, you can use:
//STEP01 EXEC PGM=NAILDUMP
//FILE DD DSN=your filename,DISP=SHR
in your JCL. But given the scarcity of information on this program, the fact it doesn't seem to appear in any of the IBM z/OS docs and the fact that there are perfectly good supported ways of doing this, I'd still maintain that it's some in-house utility. Ask your local sysprogs - even if they don't know, they should be able to see inside the JCL member.
(a) It's probably not worth much since there are all sorts of wonderful things you can do with JCL just by specifying DD commands, even with programs that do absolutely nothing, a la the infamous IEFBR14 program.
NAILDUMP is not a "normal" name for any standard IBM Mainframe (zos) utility program.
This leaves three possibilities. NAILDUMP could be:
a locally developed program, in which case you need to find the local documentation (good luck!).
a catalogued procedure fronting a standard utility. For example, DFSORT is a catalogued procedure used in many shops to front the standard system sort program.
an alias for another program. For example, ICEMAN is a commonly defined alias for the standard system sort program.
If you had access to the mainframe (or can find someone who does)
the ISRDDN utility under TSO can be used to find the actual program load module
that NAILDUMP relates to provided it is a locally developed program or is an alias for some other
standard utility program. This link
gives a brief explanation of how to do it.
If it is a catalogued procedure you can find it by searching for a member named NAILDUMP in the system default
catalogued procedure library or those specified in the JCL.
Getting to the real name can be a bit of a challenge, but once you get there it should become clear what it is being used for through context.
It seems this a case when the author who made a document is very familiar with some term ( "naildump") but not to the audience of the document.
I think you should first ask the author for clarification because even if someone answers to you what it supposes to mean they could be wrong for that case in particular.
Given your little context makes a little sense that "NAILDUMP" empties the dataset or delete it.
LogParser isn't open source and I need this functionality for an open source project I'm working on.
I'd like to write a library that allows me to query huge (mostly IIS) log files, preferably with Linq.
Do you have any links that could help me? How does a program like LogParser work so fast? How does it handle memory limitations?
It probably process the information in the log as it reads it. This means it (the library) doesn't have to allocate a huge amount of memory to store the information. It can read a chunk, process it and throw it away. It is a usual and very effective way to process data.
You could for example work line by line and parse each line. For the actual parsing you can write a state machine or if the requirements allows it, use regex.
Another approach would be a state machine that both reads and parses the data. If for some reason a log entry spans more than one line this might be needed.
Some state machine related links:
A very simple state machine written in C: http://snippets.dzone.com/posts/show/3793
Alot of python related code, but some sections are universally applicable: http://www.ibm.com/developerworks/library/l-python-state.html
If your aim is to query IIS log data with LINQ. Then i suggest you to move the Raw IIS Log data to database and query the database using LINQ. This blog post might help.
http://getsrirams.blogspot.in/2012/07/migrate-iislog-data-to-sqlce-4-database.html