Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uri normalization for remote directories #305

Open
marksantcroos opened this issue Feb 5, 2014 · 5 comments
Open

uri normalization for remote directories #305

marksantcroos opened this issue Feb 5, 2014 · 5 comments

Comments

@marksantcroos
Copy link
Contributor

While trying to debug a piece of code of Vivek, and after discussion with AndreM, we came across the following issue and conclusion:

sftp://username@hostname//etc/passwd and sftp://username@hostname/etc/passwd are supposed to be the same. However, SAGA treats them differently.

There is probably a path normalization missing somewhere.

Recording this here and will tell Vivek to use the "single slash" path format for now.

Might look into it myself too if time permits.

@marksantcroos
Copy link
Contributor Author

Got bitten by this again, some safety-net to work around it is to construct the Url like this:

remote_dir_url = saga.Url()
remote_dir_url.scheme = 'sftp'
remote_dir_url.host = host.domain
remote_dir_url.path = /var/nsa/logs

@andre-merzky andre-merzky self-assigned this Sep 14, 2014
@andre-merzky
Copy link
Member

I tried to fix a couple of things in the URL class (in utils), and got utterly lost in the code... :( I am not sure I can fix this w/o breaking other parts. I would propose to replace the URL class with something simpler and maintainable...

@oleweidner
Copy link
Contributor

Back in the days I have been on the lookout for a better Python URL class but couldn't really find one.

I would be very careful with changing behavior of the URL class as people as well as adaptors have probably silently put in their own checks and fixes in place or some of the small issues in the URL class. Changing behavior - even though it might be the 'correct' thing to do - might cause random failures elsewhere.

@mturilli
Copy link
Contributor

Is this fixed? If not, I created a PR documenting Mark's workaround. Once merged this can be closed.

@mturilli
Copy link
Contributor

@andre-merzky to be closed after fix in utils is merged

@andre-merzky andre-merzky removed their assignment Apr 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants