The file extents.c (fs/ext4/extents.c) in linux kernel 4.7.2 deals with file allocation methods.
ar.goal is calculated by a function ext4_ext_find_goal
ar.goal = ext4_ext_find_goal(inode, path, map->m_lblk);
Can anyone please explain how this function works ?
ext4_ext_find_goal() is called when we need to allocate new block.
In here, this function is called as you said.
ar.goal = ext4_ext_find_goal(inode, path, map->m_lblk);
In this context, path is not NULL. So, ext4_ext_find_goal() will find block number of that path, and return this block number.
Related
I want to put a string result of a command in WinDbg in a variable for a later use.
For example, in a memory breakpointI want to save the result of - lm1ma eip that returns me the current module, for later comparison in $spat command.
If anyone knows a better way to achieve the goal of determining if the current debugged module is a specific module, inside a conditional breakpoint, it could be also helpful.
Use as /c Name CommandString.
It creates an alias to the results of executing the specified command.
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/as--as--set-alias-
My problem is the same as the one mentioned in this answer. I've been trying to understand the code and this is what I learned:
It is failing in the file parse_xml.cgi, tries to get messages (return $message{$name}) from a file named messages (located in the html_en directory).
The $messages value comes from the method GetMessageHash in file adminprotocol-lib.pl:
sub GetMessageHash
{
return $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}
}
The $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is set in the file streamingadminserver.pl:
$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"}
I dont know anything about Perl so I have no idea of what the problem can be, for what I saw $messages{"en"} has the correct value (if I do print($messages{"en"}{'SunStr'} I get the value "Sun")).
However, if I try to do print($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"}{'SunStr'} I get nothing. Seems like $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} is not set
I tried this simple example and it worked fine:
$ENV{"HELLO"} = "hello";
print($ENV{"HELLO"});
and it works fine, prints "hello".
Any idea of what the problem can be?
Looks like $messages{"en"} is a HashRef: A pointer to some memory address holding a key-value-store. You could even print the associated memory address:
perl -le 'my $hashref = {}; print $hashref;'
HASH(0x1548e78)
0x1548e78 is the address, but it's only valid within the same running process. Re-run the sample command and you'll get different addresses each time.
HASH(0x1548e78) is also just a human-readable representation of the real stored value. Setting $hashref2="HASH(0x1548e78)"; won't create a real reference, just a copy of the human-readable string.
You could easily proof this theory using print $ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} in both script.
Data::Dumper is typically used to show the contents of the referenced hash (memory location):
use Data::Dumper;
print Dumper($messages{"en"});
# or
print Dumper($ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"});
This will also show if the pointer/reference could be dereferenced in both scripts.
The solution for your problem is probably passing the value instead of the HashRef:
$ENV{"QTSSADMINSERVER_EN_SUN"} = $messages{"en"}->{SunStr};
Best Practice is using a -> between both keys. The " or ' quotes for the key also optional if the key is a plain word.
But passing everything through environment variables feels wrong. They might not be able to hold references on OSX (I don't know). You might want to extract the string storage to a include file and load it via require.
See http://www.perlmaven.com/ or http://learn.perl.org for more about Perl.
fix code:
$$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"} = $messages{"en"};
sub GetMessageHash
{
return $$ENV{"QTSSADMINSERVER_EN_MESSAGEHASH"};
}
ref:
https://github.com/guangbin79/dss6.0.3-linux-patch
I understand vma->fault() will take two arguments which are vma and vmf. But I am not sure what vma->fault() will do inside of itself because I cannot find the code or document that talks about the initialization of this field in vm_area_struct->vm_ops->fault().
If I understand correctly, you are looking for implementation vma->fault(), which is being executed in mm/memory.c in __do_fault() function:
ret = vma->vm_ops->fault(vma, &vmf);
TL;DR
Short answer: special_mapping_fault() function set up as .fault callback.
Long story
When trying to find thing like this, one shouldn't underestimate power of simple Unix tools, like grep. Knowing that .fault callback belongs to memory management, we know that we should look into mm/ directory. So here is the answer:
$ grep -sIrHn '\.fault = ' mm/*
And the output is next:
mm/hugetlb.c:2594: .fault = hugetlb_vm_op_fault,
mm/mmap.c:3001: .fault = special_mapping_fault,
mm/mmap.c:3007: .fault = special_mapping_fault,
Investigating further we can figure out that mm/hugetlb.c is part of HugeTLB FS implemetation, hence has nothing to do with your case.
For both other cases you can see that special_mapping_fault() function is using as .fault callback.
I've written a duplicate finder in Java, but I need to include hard link support for it. Unfortunately, there seems to be no way to dig out a file's MFT entry in Java.
Although there is a method called fileKey() in the BasicFileAttributeView class, it won't work on the NTFS file system (I haven't tested it on ext yet).
I also found the method isSameFile() (in java.nio.file.Path). Does anyone know how this method works? It seems to be doing the right thing, but it returns a Boolean value, so it is worthless for me (I wish to put the results into a map and group them by their MFT entries).
I can always compare the creation times, modification times, etc. for each file, but this is just giving up.
Is there any way to accomplish what I am trying to do in either C++ or Java? I care more about making it work on NTFS than ext.
You would need to use the FILE_ID_FULL_DIRECTORY_INFORMATION structure along with the NtQueryDirectoryFile function (or the FILE_INTERNAL_INFORMATION structure along with the NtQueryInformationFile, if you already have a handle) inside ntdll.dll (available since Windows XP, if not earlier) to get the 8-byte file IDs and check if they are the same.
This will tell you if they are the same file, but not if they are the same stream of the same file.
I'm not sure how to detect if two files are the same stream from user-mode -- there is a structure named FILE_STREAM_INFORMATION which can return all the streams associated with a file, but it doesn't tell you which stream you have currently opened.
Detecting hard links is usually accomplished by calling FindFirstFileNameW. But there is a lower level way.
To get the NTFS equivalent to inodes, try the FSCTL_GET_OBJECT_ID ioctl code.
There's a unique (until the file is deleted) identifier in the BY_HANDLE_FILE_INFORMATION structure as well.
If the volume has an enabled USN Change Journal, you can issue the FSCTL_READ_FILE_USN_DATA ioctl code. Check the FileReferenceNumber member in the USN_RECORD structure
In Java you can use sun.nio.ch.FileKey which is a non-transparent enclosure for NTFS Inode. All the hard links share the same Inode.
Therefore, if you need to collect hard links, you can create FileKey from each suspect and compare them (e.g. by putting pairs of FileKey -> File into a Multimap)
I find fileKey is always null. Here is some code that can actually read the NTFS inode number. There remain many aspects I'm not happy with, not least, it relies on reflection.
import sun.nio.ch.FileKey;
import java.io.*;
import java.lang.reflect.Field;
import java.nio.file.Path;
class NTFS {
static long inodeFromPath(Path path) throws IOException, NoSuchFieldException, IllegalAccessException {
try (FileInputStream fi = new FileInputStream(path.toFile())) {
FileDescriptor fd = fi.getFD();
FileKey fk = FileKey.create(fd);
Field privateField = FileKey.class.getDeclaredField("nFileIndexHigh");
privateField.setAccessible(true);
long high = (long) privateField.get(fk);
privateField = FileKey.class.getDeclaredField("nFileIndexLow");
privateField.setAccessible(true);
long low = (long) privateField.get(fk);
long power = (long) 1 << 32;
long inode = high * power + low;
return inode;
}
}
}
i am new to matlab. While working through the Matlab GUI, i faced a problem which is as follows..i want to have 2 figure files, with one figure file calling the other. i know that just by calling the name of the 2nd fig file from the first fig file, we can call the 2nd figure. however, i also wish to send some parameters from one fig file to another.here i need to send the arguments and also obtain these parameters so as to do further processing.i havent been able to find a solution to this problem. i would be glad if someone helps me out with this problem. thanking you in advance
There are three ways I found to do this:
Method 1: Use setappdata and getappdata like so:
setappdata(0,'some_var',value)
some_other_var = getappdata(0,'some_var')
You would use setappdata() in the m-file for fig1 to store whatever data you wanted to pass around, and then call getappdata() in another m-file to retrieve it. The argument 0 to the two functions specifies the MATLAB root workspace, which is accessible by your program everywhere (i.e. it is global). As such, when you close your figures that data will still be available. You may want to use rmappdata to remove them.
Method 2: Use guidata:
Assuming you created your GUI with GUIDE, then you have access to a structure called handles which is passed around everywhere and which you can edit, and so you can do this in a GUI callback:
handles.some_var = some_value
guidata(hObject,handles)
Then you can access handles.some_var elsewhere in some other callback (because handles is automatically passed into it for you) in your other m-file:
some_other_var = get(handles.some_var)
Method 3: Use UserData:
Store the variable you want from your first figure:
set(name_of_fig, 'UserData', some_var)
Then to get it from your other one:
some_other_var = get(name_of_fig, 'UserData')
(Disclaimer: My actual knowledge of MATLAB is not all that great, but it helps to be able to find good resources like this and this, and even this from the official docs. What I've written here may be wrong, so you should definitely consult the docs for more help.)
I would do like this (assuming you're using the GUI builder GUIDE).
Let's say that your figures/m-files are named firstFigure.fig/m and secondFigure.fig/m. In the code of firstFigure, just call secondFigure and pass your parameters as arguments:
someNumber = 1;
someText = 'test';
aMatrix = rand(3);
secondFigure(someNumber, someText, aMatrix);
The arguments will be available to secondFigure as a variable varargin in the callback functions
function varargout = secondFigure(varargin)
and
function secondFigure_OpeningFcn(hObject, eventdata, handles, varargin)
varagin is a cell structure; use cell2mat and char to convert it back:
theNumber = cell2mat(varargin(1));
theText = char(varargin(2));
theTextAgain = cell2mat(varargin(2));
theMatrix = cell2mat(varargin(3));
This may help:
http://www.mathworks.ch/matlabcentral/newsreader/view_thread/171989
The easiest method is to wrap the parameters in a cell array and send them directly to the GUI constructor. A call with two parameters might look like:
figure2({param1, param2})
Then you can unpack the arguments in the opening function (figure2_OpeningFcn) with code like:
handles.par1 = varargin{1}{1};
handles.par2 = varargin{1}{2};
These lines must be placed somewhere before the line that says guidata(hObject, handles);. Then you can access handles.par1 and handles.par2 directly in all the other callbacks.
I assume you are using GUIDE to generate your GUI. You can find figure2_OpeningFcn in figure2.m which will be located in the same directory as figure2.fig.
Note: you can also return values from a figure, returnvalue = my_figure({my_input}). If you'd like instructions on that too, leave a comment and I'll extend my answer.