Win32's PathResolve is resolving \temp into c:\temp, even if I run the function from another drive.
In addition, IsRelative() returns false for '\temp' - which makes me wonder what kind of resolution it actually thinks it's doing for this path.
Perhaps driveless paths default to your system drive?
Related
I need to figure out if a given (UNC) path actually points/ends/is the given path (directory).
Example: "\?\UNC\machine1\shared1". GetFinalPathNameByHandle will result in "\?\UNC\machine1\shared1".
However, if there's a symlink "sym" inside shared1 and the given path is "\?\UNC\machine1\shared1\sym", having "sym" be created with mklink and pointing to "\machine2\shared2", the result given by GetFinalPathNameByHandle is "\?\UNC\machine2\shared2".
Now, we have a QNAP NAS, with "home" folders enabled - meaning that each domain user, when navigating to "\nas\home", will end up in its own directory.
GetFinalPathNameByHandle for "\?\UNC\nas\home" results in "\?\UNC\nas\home", while I would need to get my hands on the actual directory name, like "\?\UNC\nas\homes\user_name". I do not need to read/write - I just need to know that "\?\UNC\nas\home" is really not "\?\UNC\nas\home".
This idea then propagates to any similar scenarios when "\machine\folder" ends up somewhere else (per user). Say I do not even need to know where does it really end, just that there's some kind of reparsing happening...
Any ideas?
I am trying to implement server.execute() via an include from a virtual functions library (<!-- #include virtual="lib/functions.asp"-->) that I can call on from any subfolder in the system. I am trying to implement a new function that should exist on all pages in our system, and it would be virtually unfeasible to go in and add it manually to every single page. And I need it to be implemented in such a way that it does not interfere with the code on any page which is why I am doing it as a server.execute() in a virtual lib that I know already exists everywhere in the system.
For example:
'location of routine.asp = https://example.com/admin/routine/routine.asp
Server.Execute("routine/routine.asp")
'Will work if I add the virtual lib from an ASP-page in the admin subfolder, but not if I call it from another subfolder
Server.Execute("https://example.com/admin/routine/routine.asp")
'Does not work, because server.execute can't handle that kind of fixed path
The documentation clearly states that colons and double-slashes are not allowed, but I can't figure out how I can make sure the execution of the file happens no matter where in the system it's called from.
Question: How can I make server.execute(path)'s path handle a fixed path, or change the path dynamically to make sure I can always target the file correctly?
If you want to use an absolute path make sure you are using an absolute path (full path from the root).
Think you simply need to specify the absolute path explicitly;
Server.Execute("/admin/routine/routine.asp")
On macOS, /tmp is a symlink to /private/tmp, yet when I do this:
URL(fileURLWithPath: "/tmp").resolvingSymlinksInPath().path
it returns "/tmp".
(I've reported this to Apple, and they closed it as a duplicate, so they know about it already.)
Is it publicly known what paths have incorrect values returned by this method? If it's just a couple paths which are hardcoded internally, then it'd be easier to check for them, than to rewrite a working resolvingSymlinksInPath() from scratch.
See the documentation for resolvingSymlinksInPath:
If the name of the receiving path begins with /private, this property strips off the /private designator, provided the result is the name of an existing file.
So if the result is, say, /private/var and there is /var then that is what is returned.
This appears to be based on a convention only, there is no check that the resultant path references the same filesystem item. E.g. create /a, /private/a and sym link /test to /private/a then resolve symlinks for /test and the result is /a despite that not being the same as /private/a
I need to get a safe temp folder where I could store temporary files for my application, but so far my research has lead me to conclusion that all approaches I've found are flawed.
The first idea was to use GetTempPath function, but that causes two problems:
The folder might not exist, so I would have to truncate folders one by one up to root, and recreate them if they do not exist back to full path (error prone, tedious)
From "Larry Osterman's WebLog" click it seems that GetTempPath might fallback to USERPROFILE or Windows directory and extract whole lot of files right in there, which is SUPER BAD(TM)!
In the same post, there is a suggestion to use GetEnvironmentVariable, but this seems a dangerous function to me (missing TMP & TEMP envvars for instance).
Is there a cleaner function I could use? Seems that SHGetKnownFolderPath has no clue what temp folder is.
Your program is probably not the only one to rely on GetTempPath, so it's reasonable to expect it to return a proper writable path. Especially since Windows automatically initializes the TMP and TEMP environment variables for you; someone would have to go to some trouble to override them, and it would be their responsibility to make sure the change did not mess up their system.
I would go ahead and assume GetTempPath works properly, and worry about failures when you try to create the temporary file - there are other errors that might occur at that time that you need to check for anyway.
An idea would be to get the path where your application is (GetModuleFileNameEx combined with GetModuleHandle(NULL) and GetCurrentProcess) since this directory cannot be deleted under windows as long as your application is running from it (maybe I'm wrong ...some years ago I couldn't do this :) ) and in this directory create a temporary directory.
Your first bullet point is the solution. Wrap it up in a method so that you don't duplicate code.
According to this answer, Boost's Filesystem library can be used for this.
I'm writing some code that at run time may create or delete directories within the project path. I haven't really used ruby for file processing so i'm really uneasy about having code that, with a few mistypes weeks down the line, could result in wiping other directories outside of my project path.
Is there anyway to make it impossible for the program to delete files outside of its own path regardless of whats typed in destructive calls?
Pathname is a wrapper class for almost any file operations.
require "pathname"
path= Pathname.new("/home/johannes")
path.directory? # => true
path.children # => [#<Pathname:.bash_history>, #<Pathname:Documents>, #<Pathname:Desktop>]
path.children.each do |p|
p.delete if p.file?
end
Pathname#children does not contain . or .. so you don't accidently walk up the tree instead of down. If you still don't trust in the code, you can even check if on path is contained in another
Pathname.new("test") <=> Pathname.new("test/123") # => -1
You might want to create a wrapper method around your favourite delete method (or, perhaps, around whole class, because not only deleting files is potentially destructive file operation), which would expand all the submitted paths and check whether they begin with your "sandbox" path). You can also try to redefine delete method, if you are willing to cripple it through whole application.
And maybe the cleanest solution of them all would be to create a new user on your system and run your program as him.
On a POSIX system, you can use Dir.chroot to change the root that your application sees. Then ALL actions, not just delete ones, will be limited to the project directory. This does mean that external commands will be unavailable unless you make them part of your project directory as well.
This is the standard 'sandboxing' method used in Unix based systems. It can be difficult to setup (eliminating all external dependancies is sometimes hard), but affords significant protection when configured properly.
You could generate an Array of filenames in your project directory using
my_files = Dir["/bla/bla/your/directory/**/*"]
and then simply check if the filename passed to your "delete" function exist in your my_files array.
I'm sure there is a more elegant solution, but this could work ^_^
You could use File.expand_path and File.dirname on the input, and check that against __FILE__. So something like this might work:
File.delete(path) if File.dirname(File.expand_path(path)).include? File.dirname(File.expand_path(__FILE__))
I've got automated tests that routinely create and wipe out directories. I've taken two approaches:
Use /tmp as much as possible. The 'tmpdir' standard library module will create temporary directories which will be destroyed when your program exits. Or,
When the code creates a directory that it will later be deleting, it drops a marker file into the directory. When it comes time to delete the directory, if the marker file is not found, the code refuses to delete the directory. A marker file might be called ".ok_to_delete", for example.