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
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 copy entire file from S3 to HDFS through shell using below wild command:
wget https://export.xyz.com/Disabilities/*/*/*/*_0620.csv.zip
I am getting error: ERROR 404: Not Found
When I am using URL of one specific file, able to copy.
Please let me know how can I use wildcard in URL.
You can't. Using wildcards is only applicable where all possibilities are already known:
In a shell the operating system already knows all files of a directory: issuing ls *.log only works because this can be matched against all filenames that occur.
In SQL the DBMS already knows all table columns and all data rows of the tables: issuing SELECT * FROM people WHERE name LIKE '%Rogers' only works because all table's column names are already available, and because the filter can be matched against all rows that exist.
In a regular expression the text to be operated on is already everything that needs to be known: searching for p+ only works because its parts can be matched against i.e. opposing forces.
A uniform resource locator (URL) can never have wildcards, because then it wouldn't be uniform anymore. How should WGET (or any other HTTP client) should know which possibilities can be filled into a potential wildcard placeholder? Let alone know that * is by you meant as a wildcard and not a literal part of the URI? You're basically asking for "which URLs exist in the internet" and I wonder which answer you expect.
You have to come up with all permutations yourself, i.e. a list of all URLs that WGET can then process:
https://export.xyz/Disabilities/NY/NYC/0620/file_0620.csv.zip
https://export.xyz/Disabilities/NY/NYC/0720/file_0620.csv.zip
https://export.xyz/Disabilities/NY/NYC/0820/file_0620.csv.zip
In doubt, this list can be very big and contain URLs that indeed don't exist (and logically never will), as it will simply come out as HTTP status 404 then - all you will waste is a tiny bit of traffic and time.
wget -r --no-parent -A '*_0620.csv.zip' https://export.xyz.com/Disabilities/
may work, I'm not 100% sure. -A sets the list of acceptable arguments, you may also have to accept directory patterns as well.
I have the two folder paths as string. How to check if two paths point to same folder location. I do not want to compare the string as it will not be the proper way. I tried with File.identical? but it returns false as it seems to expect two file paths not folder paths as agruments. For your information, I want to use this code in Ruby filter plugin in Logstash
I don't see anything improper in comparing strings if they provide precise and correct location. If File.identical? doesn't work and Dir does't provide similar method, I would just convert the paths with File.realdirpath() and compare them.
File.realdirpath("first/path/") == File.realdirpath("second/path/")
It follows symlinks.
https://ruby-doc.org/core-2.5.0/File.html#method-c-realdirpath
If you are on a Unix-like system and really distrust string comparisons, you can compare inode numbers.
File.stat(File.realdirpath("first/path/")).ino == File.stat(File.realdirpath("second/path/")).ino
EDITED
Didn't notice your comment about being on Windows. I don't know how File::Stat exactly works there, but it should be available and using info it provides might be better than string comparison.
File.realpath(folder_path) == File.realpath(other_folder_path)
This method returns string with absolute pathname in the actual filesystem not containing symlinks or dots.
Unlike File.realdirpath, all components of the pathname must exist when this method is called.
Whenever I add a new file to the project, it is added with the default location of "Relative to Group" and a problematic path of (for example):
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift
It's not as if I put the file in another user's directory. In this case, ../myUsername resolves to .. Same with every other double dot. You could simplify it as follows:
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift
../../../../Folder/Foo/Foo/Foo/Bar.swift
../../../Foo/Foo/Foo/Bar.swift
../../Foo/Foo/Bar.swift
../Foo/Bar.swift
Bar.swift
Because it literally is going down the path then going back up the same way. It is equivalent to running cd ../; cd ~- in a shell.
I expected the path to be simply Bar.swift. This causes many problems when using shared code because other people have the project in different places with different usernames.
The only solution I have found so far is manually editing the project.pbxproj file. What is causing this problem and what should I do to fix it?
Note: I suspect that this might have to do something with the case of the username due to the fact that the username is as far back as the path goes.
EDIT: Here is a screenshot (red is my username, and green is the app name):
Also, cding to the directory and running realpath ../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift returns Bar.swift.
EDIT 2: My suspicions were right about the username being case-sensitive! Look what happens when I set the Location to Absolute Path:
Previously, the username was only Title case (../MyUsername, /Users/MyUsername, etc.). However, now Xcode seems to go:
Down the directory tree from the lowercase username (to the group folder)...
Past the directory containing the project...
Into the directory containing the file...
Back up to the Users directory...
Down the same path with the Title case username.
I think that this is a bug in Xcode. If I had to guess, what happens internally is:
Xcode gets the absolute path to the file
From a file picker while adding
From a file picker while relocating by pressing the folder icon in the Location section
Somehow from creating a new file(?)
This path uses the Title case username.
Xcode gets the absolute group path
From its records (project.pbxproj?)
For some reason, this path uses the lowercase username
Xcode tries to figure out the path from #1 relative to the path from #2.
For example, if the path to the file was /foo/bar/baz.swift, and the group was /foo, the intended result is bar/baz.swift.
Xcode starts at the absolute path to the group (because the end path should be relative to the group).
Xcode looks at both paths and compares them. /Users/myusername/Folder/Foo/Foo/Foo vs /Users/MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
Xcode sees that the only differences are:
At the end of the path (one has the filename and the other does not)
In the username (myusername vs MyUsername)
Xcode moves up to the farthest problem up the file tree using the double dot (../). /Users/myusername/Folder/Foo/Foo/Foo/../../../../.., or simply /Users.
Xcode starts down again, but this time uses the remaining portion of the absolute path for the file (Xcode never goes back down to /Users because it is the same for both paths).
Xcode continues all the way to the filename, using the Title case username. /Users/myusername/Folder/Foo/Foo/Foo/../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
When location is set to Relative to Group, the path to the group is implied, so the previous path simply becomes:
../../../../../MyUsername/Folder/Foo/Foo/Foo/Bar.swift.
Familiar?
Anyways, how do I fix that?????
It turns out that the problem was that I had my home directory path set to a different capitalization than the actual folder.
I need to reference patients.json from patients.go, here's the folder structure:
If I do:
filepath.Abs("../../conf/patients.json")
it works for go test ./... but fails for revel run
If I do:
filepath.Abs("conf/patients.json")
the exact opposite happens (revel is fine but tests fail).
Is there a way to correctly reference the file so that it works both for tests and normal program run?
Relative paths are always interpreted / resolved to a base path: the current or working directory - therefore it will always have its limitations.
If you can live with always taking care of the proper working directory, you may keep using relative paths.
What I would suggest is to not rely on the working directory, but an explicitly specified base path. This may have a default value hard-coded in your application (which may be the working directory as well), and you should provide several ways to override its value.
Recommended ways to override the base path to which your "relative" paths are resolved against:
Command line flag (see flag package)
Environment variable (see os.Getenv())
(Fix named) Config file in user's home directory (see os/user/User and os/user/Current())
Once you have the base path, you can get the full path by joining the base path and the relative path. You may use path.Join() or filepath.Join(), e.g.:
// Get base path, from any or from the combination of the above mentioned solutions
base := "/var/myapp"
// Relative path, resource to read/write from:
relf := "conf/patients.json"
// Full path that identifies the resource:
full := filepath.Join(base, relf) // full will be "/var/myapp/conf/patients.json"
I've never used Revel myself but the following looks helpful to me:
http://revel.github.io/docs/godoc/revel.html
revel.BasePath
revel.AppPath
This is not the problem with path, but the problem with your design.
You should design your code more careful.
As far as I can tell, you share same path in your test file and reveal run. I guess that maybe you hard code your json path in your model package which is not suggested.
Better way is
model package get json path from global config, or init model with json path like model := NewModel(config_path). so reveal run can init model with any json you want.
hard code "../../conf/patients.json" in your xxxx_testing.go