RtlDosPathNameToNtPathName_U on "\\?\C:" Returns Invalid Path - winapi

Why is it that when I call RtlDosPathNameToNtPathName_U on the path \\?\C:, instead of getting back
\??\C:
I get back
\??\C:\฀\\?\C:
which is clearly incorrect?
Code snippet (in D):
struct CurDir { UnicodeString DosPath; HANDLE Handle; }
extern (Windows) static bool RtlDosPathNameToNtPathName_U(
in const(wchar)* DosPathName, out UnicodeString NtPathName,
out const(wchar)* NtFileNamePart, out CurDir DirectoryInfo);
wchar[] toNtPath(const(wchar)[] path)
{
UnicodeString ntPath;
CurDir curDir;
const(wchar)* fileNamePart;
enforce(RtlDosPathNameToNtPathName_U(path.ptr, ntPath,
fileNamePart, curDir));
try
{ return ntPath.Buffer[0 .. ntPath.Length / ntPath.Buffer[0].sizeof].dup; }
finally { RtlFreeHeap(RtlGetProcessHeap(), 0, ntPath.Buffer); }
}
writeln(toNtPath(r"\\?\C:")); //Returns the weird string
Update:
I figured out the problem -- see my answer.

RtlDosPathNameToNtPathName_U is giving you the correct output. The reason you see a weird-looking character in the middle is because UNICODE_STRINGs are not required to be null-terminated (which I'm sure you know already). The file name \??\C:\ is a completely valid native-format file name. I suspect what you really want is to prepend the device name instead of just referring to the GLOBAL?? directory like what RtlDosPathNameToNtPathName_U has done.
To do that, simply call NtQuerySymbolicLinkObject on \??\x:, where x is the drive letter that the path is using, and prepend the result. If it's a UNC path, prepend \Device\Mup. And so on for the other types of paths (if there are any).

I figured out the problem myself, with #wj32's help: I'd totally forgotten that the input to RtlDosPathNameToNtPathName_U needed to be null-terminated, and my code didn't handle that properly. Thanks for everyone's help!

Related

how does putty generate the names of it's named pipes?

agent_named_pipe_name.c has this:
char *agent_named_pipe_name(void)
{
char *username = get_username();
char *suffix = capi_obfuscate_string("Pageant");
char *pipename = dupprintf("\\\\.\\pipe\\pageant.%s.%s", username, suffix);
sfree(username);
sfree(suffix);
return pipename;
}
My question is... how does capi_obfuscate_string("Pageant") work? It's defined in cryptoapi.c and appears to just pass the parameter that's passed to it through sha256 and that's it. Except that when I do sha256('Pageant') locally what I get doesn't match the named pipe name that I got on my system. Further, one would think that if that is all that it were doing that running ./pageant --openssh-config pageant.conf on two systems, under different user accounts, would yield the same result on both systems and yet it's not.
Any ideas?

How to get file as a resource with Storage?

I am trying to lock a file with the flock function but I am not able to do it. I work with Laravel 8 and Storage Class.
The code is as follows:
$disk = Storage::disk('communication');
$file_name = 'received.json';
$file_exists = $disk->exists($file_name);
if($file_exists){
flock($disk->get($file_name), LOCK_EX);
...
}
The problem I'm having is that when I invoke the get() function on the file path, it returns the contents of the file (a string), which causes the following error:
flock() expects parameter 1 to be resource, string given
I need to know how to get file as a resource and not the content of the file.
Could someone help me and tell me how to do it?
Thank you very much in advance.
You can use Storage::readStream() method
if($file_exists){
$stream=Storage::disk('communication')->readStream($file_name);
flock($stream, LOCK_EX);
}
As per php doc
flock(resource $stream, int $operation, int &$would_block = null): bool
First param needed stream.flock() allows you to perform a simple
reader/writer model which can be used on virtually every platform
(including most Unix derivatives and even Windows).
Ref:https://www.php.net/manual/en/function.flock.php

How to use a function as a string while using matching pattern

I want to make use of functions to get the full path and directory name of a script.
For this I made two functions :
function _jb-get-script-path ()
{
#returns full path to current working directory
# + path to the script + name of the script file
return $PWD/${0#./*}
}
function _jb-get-script-dirname ()
{
return ${(_jb-get-script-path)##*/}
}
as $(_jb-get-script-path) should be replaced by the result of the function called.
However, I get an error: ${(_jb-get-script-path)##*/}: bad substitution
therefore i tried another way :
function _jb-get-script-path ()
{
return $PWD/${0#./*}
}
function _jb-get-script-dirname ()
{
local temp=$(_jb-get-script-path);
return ${temp##*/}
}
but in this case, the first functions causes an error : numeric argument required. I tried to run local temp=$(_jb-get-script-path $0) in case the $0 wasn't provided through function call (or i don't really know why) but it didn't change anything
I don't want to copy the content of the second fonction as i don't want to replicate code for no good reason.
If you know why those errors happen, I really would like to know why, and of course, if you have a better solution, i'd gladely hear it. But I'm really interessed in the resolution of this problem.
You need to use echo instead of return which is used for returning a numeric status:
_jb-get-script-path() {
#returns full path to current working directory
# + path to the script + name of the script file
echo "$PWD/${0#./*}"
}
_jb-get-script-dirname() {
local p="$(_jb-get-script-path)"
echo "${p##*/}"
}
_jb-get-script-dirname

tmux titles-string not executing shell command

I have the following lines in my ~/.tmux.conf
set-option -g set-titles on
set-option -g set-titles-string "#(whoami)##H: $PWD \"#S\" (#W)#F [#I:#P]"
This has worked in the past but after upgrading to 2.0 shell commands are no longer executed. I now see in my title:
#(whoami)#myhostname.local: /Users/lander [..rest..]
According to the man page, this should work:
status-left string
Display string (by default the session name) to the left of the status
bar. string will be passed through strftime(3) and formats (see
FORMATS) will be expanded. It may also contain any of the following
special character sequences:
Character pair Replaced with
#(shell-command) First line of the command's output
#[attributes] Colour or attribute change
## A literal `#'
Well done for reading the code, it's simple really: set-titles-string switched to using formats which don't expand #(). Patching this is easy, and no, it's not good enough to reinstate status_print() to tmux.h, instead, job expansion should be a separate function and used from status_replace() and format_expand(). No idea when this will get done.
Thanks for playing.
The code that performed the task your are mentioning is no longer present in version 2.0. That's the short answer to the question above. Either the documentation hasn't been updated to reflect this, or this was done accidentally and is a bug.
What follows is exactly why I think this is the case. I'm at the end of my lunch break, so I can't create a patch for this right now. If no one else gets around to fixing this from here, I will take a stab at it this weekend.
I checkout out the git repository and took a look at code changes from version 1.9a -> 2.0.
The function that actually does this replacement is status_replace() in status.c. This still seems to work, as the command processing works in the status lines, which still call this function.
In version 1.9a, this was also called from server_client_set_title() in server-client.c, around line 770. It looks like this:
void
server_client_set_title(struct client *c)
{
struct session *s = c->session;
const char *template;
char *title;
template = options_get_string(&s->options, "set-titles-string");
title = status_replace(c, NULL, NULL, NULL, template, time(NULL), 1);
if (c->title == NULL || strcmp(title, c->title) != 0) {
free(c->title);
c->title = xstrdup(title);
tty_set_title(&c->tty, c->title);
}
free(title);
}
In version 2.0, this call has been replaced with (now down around line 947):
void
server_client_set_title(struct client *c)
{
struct session *s = c->session;
const char *template;
char *title;
struct format_tree *ft;
template = options_get_string(&s->options, "set-titles-string");
ft = format_create();
format_defaults(ft, c, NULL, NULL, NULL);
title = format_expand_time(ft, template, time(NULL));
if (c->title == NULL || strcmp(title, c->title) != 0) {
free(c->title);
c->title = xstrdup(title);
tty_set_title(&c->tty, c->title);
}
free(title);
format_free(ft);
}
It looks like calls to format_expand_time() and status_replace() might be mutually exclusive. That is the part that might take a bit of effort to fix -- getting the old function call back in there without breaking whatever new functionality they've just added.

Jackrabbit XPath Query: UUID with leading number in path

I have what I think is an interesting problem executing queries in Jackrabbit when a node in the query path is a UUID that start with a number.
For example, this query work fine as the second node starts with a letter, 'f':
/*/JCP/feeadeaf-1dae-427f-bf4e-842b07965a93/label//*[#sequence]
This query however does not, if the first 'f' is replaced with '2':
/*/JCP/2eeadeaf-1dae-427f-bf4e-842b07965a93/label//*[#sequence]
The exception:
Encountered "-" at line 1, column 26.
Was expecting one of:
<IntegerLiteral> ...
<DecimalLiteral> ...
<DoubleLiteral> ...
<StringLiteral> ...
... rest omitted for brevity ...
for statement: for $v in /*/JCP/2eeadeaf-1dae-427f-bf4e-842b07965a93/label//*[#sequence] return $v
My code in general
def queryString = queryFor path
def queryManager = session.workspace.queryManager
def query = queryManager.createQuery queryString, Query.XPATH // fails here
query.execute().nodes
I'm aware my query, with the leading asterisk, may not be the best, but I'm just starting out with querying in general. Maybe using another language other than XPATH might work.
I tried the advice in this post, adding a save before creating the query, but no luck
Jackrabbit Running Queries against UUID
Thanks in advance for any input!
A solution that worked was to try and properly escape parts of the query path, namely the individual steps used to build up the path into the repository. The exception message was somewhat misleading, at least to me, as in made me think that the hyphens were part of the root cause. The root problem was that the leading number in the node name created an illegal XPATH query as suggested above.
A solution in this case is to encode the individual steps into the path and build the rest of the query. Resulting in the leading number only being escaped:
/*/JCP/_x0032_eeadeaf-1dae-427f-bf4e-842b07965a93//*[#sequence]
Code that represents a list of steps or a path into the Jackrabbit repository:
import org.apache.commons.lang3.StringUtils;
import org.apache.jackrabbit.util.ISO9075;
class Path {
List<String> steps; //...
public String asQuery() {
return steps.size() > 0 ? "/*" + asPathString(encodedSteps()) + "//*" : "//*";
}
private String asPathString(List<String> steps) {
return '/' + StringUtils.join(steps, '/');
}
private List<String> encodedSteps() {
List<String> encodedSteps = new ArrayList<>();
for (String step : steps) {
encodedSteps.add(ISO9075.encode(step));
}
return encodedSteps;
}
}
Some more notes:
If we escape more of the query string as in:
/_x002a_/JCP/_x0032_eeadeaf-1dae-427f-bf4e-842b07965a93//_x002a_[#sequence]
Or the original path encoded as a whole as in:
_x002f_a_x002f_fffe4dcf0-360c-11e4-ad80-14feb59d0ab5_x002f_2cbae0dc-35e2-11e4-b5d6-14feb59d0ab5_x002f_c
The queries do not produce the wanted results.
Thanks to #matthias_h and #LarsH
An XML element name cannot start with a digit. See the XML spec's rules for STag, Name, and NameStartChar. Therefore, the "XPath expression"
/*/JCP/2eeadeaf-1dae-427f-bf4e-842b07965a93/label//*[#sequence]
is illegal, because the name test 2eead... isn't a legal XML name.
As such, you can't just use any old UUID as an XML element name nor as a name test in XPath. However if you put a legal NameStartChar on the front (such as _), you can probably use any UUID.
I'm not clear on whether you think you already have XML data with an element named <2eead...> (and are trying to query that element's descendants); if so, whatever tool produced it is broken, as it emits illegal XML. On the other hand if the <2eead...> is something that you yourself are creating, then presumably you have the option of modifying the element name to be a legal XML name.

Resources