Comments (10)
Python fixed here: 95ddc32
from pftool.
This needs to be fixed at some point, but the pf* wrapper scripts now change relative paths to full paths. So, we can get by without fixing this for Secure Campaign because we'll only allow users to use these wrapper scripts.
from pftool.
pftool could generate absolute paths by either (a) calling realpath(), or (b) simulating realpath() by prepending cwd and then canonicalizing using just regular expressions.
However, for marfs paths, the former approach would fail on back-end nodes where there is no marfs fuse-mount. The latter approach would produce unexpected results for paths that include symlinks that refer to directories with parents that are different from the parent of the symlink. (For example: "./my_dir_link/../blah" is not necessarily the same as "./blah".)
Rather than having pf-scripts do explicit string-processing on the paths, it seems like one simple and safe alternative would be for pf-scripts to invoke realpath(). The nice thing about that approach is that those scripts run on the front-ends, with e.g. marfs_fuse mounted, so symlinks can be followed.
Another option is for pftool to implement its own realpath(), using Path::readlink(), etc.
from pftool.
On second thought, there's more to be discussed here.
from pftool.
Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.
from pftool.
Seems like realpath in the scripts gets us pretty far
Is there a scriptable version of realpath or do we need to write a 4 line C program?
From: Jeff Inman [mailto:[email protected]]
Sent: Friday, July 22, 2016 10:48 AM
To: pftool/pftool
Subject: Re: [pftool/pftool] Relative paths resolve incorrectly - (#15)
Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/15#issuecomment-234595236, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALNxmfqGiY5fGax5rfX0Fjye9vPvL--Qks5qYPQxgaJpZM4H57vm.
from pftool.
I already modified the pf-scripts to use abspath to get rid of weirdness with relative paths, switching that over to realpath would be very trivial (or a combination of both).
os.path.realpath(path) https://docs.python.org/2/library/os.path.html#os.path.realpath
Return the canonical path of the specified filename, eliminating any symbolic links encountered in the path (if they are supported by the operating system).New in version 2.2.
- Dave
On Jul 22, 2016, at 11:23 AM, garygrider [email protected] wrote:
Seems like realpath in the scripts gets us pretty far
Is there a scriptable version of realpath or do we need to write a 4 line C program?
From: Jeff Inman [mailto:[email protected]]
Sent: Friday, July 22, 2016 10:48 AM
To: pftool/pftool
Subject: Re: [pftool/pftool] Relative paths resolve incorrectly - (#15)Another issue is that pftool called from pf-scripts doesn't know what the working-dir was, when the pf-scripts were invoked. This information could be passed as another argument to pftool, but it's starting to look easier to just call realpath() in the scripts.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/15#issuecomment-234595236, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALNxmfqGiY5fGax5rfX0Fjye9vPvL--Qks5qYPQxgaJpZM4H57vm.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #15 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ADRbVdmc0zKbAQQF0GHH5VsHZ73Wpp5kks5qYPyAgaJpZM4H57vm.
from pftool.
@so, this popped up in production this week. I need to test it, but DNE is creating headaches. I used os.path.abspath in my patch, but not os.path.realpath. The former does not resolve symlinks, and DNE uses symlinks to shuffle users around between metadata servers.
Anyone see any problems with simply resolving symlinks prior to handing them to pftool?
Update: I can confirm this works with DNE.
from pftool.
I think that will suffice for the next release. Leave the issue open so that someone can actually dig into the pftool issue.
from pftool.
This has been fixed by 5e4fe55 in pftool proper.
from pftool.
Related Issues (20)
- Change python shebang to use system python in python wrappers via autotools
- Replace optparse with argparse HOT 1
- Refactor error checking for config file
- Remove references to threading in README
- Remove all code related to threaded vs not threaded in python wrappers HOT 1
- Unable to use pfrsync HOT 1
- Pftool writes fail into the root of a MarFS repository - HOT 5
- Pftool will not build HOT 3
- avoid touching destinations until doing actual work on them HOT 3
- coordinate logging cmd-line parameters and function implementations HOT 1
- missing config NS results in obscure "failed to stat path" HOT 2
- restart after SIGINT occasionally gets rename failures on individual chunk-files HOT 1
- changes to CTF for temp-files need to be made to CTA, as well
- pfcp shouldn't try to create temp-files on /dev/null HOT 1
- fatal error: openssl/md2.h: No such file or directory HOT 1
- Unable to build pftool without MarFS - HOT 1
- Pftool fails to build as a subdirectory of marfs HOT 2
- After using disable-marfs with configure not able to make HOT 4
- While running any command of pftool getting segmentation fault HOT 13
- upgrade python wrappers to be complatible with python3 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pftool.