virtualbox scripts translates "\r" substrings in VM basepath

Bug #1334070 reported by Vasiliy Pleshakov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Committed
High
Vasiliy Pleshakov

Bug Description

Environment:
fuel 5.0
Windows 7/8
Cygwin x86_64 v6.1
fresh installation of VirtualBox v 4.3.12
windows username starts with "r" (e.g. "Ruslan", "russiarules")

Steps to reproduce:
1. open VirtualBox preferences and make sure that Default Mashine Folder set to "C:\Users\<username_starts_with_r>\Virtualbox VMs\" OR set Default Mashine Folder to any folder which starts with r letter.
2. run Cygwin
3. navigate to folder there virtualbox scripts located.
4. launch scripts with command "./launch.sh"

Expected result:
1. All VMs created and configured properly. All VMs runs normaly.
2. all VMs files resides at Default Mashine Folder
Actual result:
1. fuel-master VM creates but scripts does not able to add disk to it.
2. all VMs are created and VMs runs normaly. But all VMs files resides in several locations: at c:\cygwin\home, at c:\fuel-*\ folders.

Workaround:
set Default Mashine Folder to any folder there is no "r" letter at the start of folders in the path.

Why it happens:
If foldername starts with "r" letter then there is a "\r" substring in path (windows notation). When scripts read value of Default Mashine Folder at line functions/vm.sh:20 "\r" substring interprets into Carriage Return character.

Revision history for this message
Vasiliy Pleshakov (vpleshakov) wrote :
Revision history for this message
Vasiliy Pleshakov (vpleshakov) wrote :

It looks like we should remove "-e" parameter in echo command at line functions/vm.sh:20
becouse man echo says: -e enable interpretation of backslash escapes
Or we should change "-e" to "-E" :
-E disable interpretation of backslash escapes (default)

Changed in fuel:
importance: Undecided → High
assignee: nobody → Fuel Library Team (fuel-library)
milestone: none → 5.1
Changed in fuel:
assignee: Fuel Library Team (fuel-library) → Fuel DevOps (fuel-devops)
Revision history for this message
Andrew Woodward (xarses) wrote :

As a alternate we should be able to outright replace \ with / in dirpaths in windows (since XP) and especally inside cigwin

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-main (master)

Fix proposed to branch: master
Review: https://review.openstack.org/102630

Changed in fuel:
assignee: Fuel DevOps (fuel-devops) → Vasiliy Pleshakov (vpleshakov)
status: New → In Progress
Revision history for this message
Vasiliy Pleshakov (vpleshakov) wrote :

replace \ with / in dirpaths not a good choice. This is why:
in add_disk_to_vm() function we construct path to file and then pass it to VBoxManage as argument.
On Windows VBoxManage wouldn't understand slashes in path and will put file somethere else.

As an alternative inside cygwin:
1. we can convert all windows-style paths to cygwin paths ("cygpath $winpath"),
2. treat path as unix-style path
3. convert path ("cygpath -w $unixpath") each time we pass it to windows tools
But it will force us to pollute with "case "$(uname)" in CYGWIN*) ... esac" all other the code.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to fuel-main (master)

Reviewed: https://review.openstack.org/102630
Committed: https://git.openstack.org/cgit/stackforge/fuel-main/commit/?id=aa0e11b66798ac16f6f382fa3974da61f5a029a6
Submitter: Jenkins
Branch: master

commit aa0e11b66798ac16f6f382fa3974da61f5a029a6
Author: Vasiliy Pleshakov <email address hidden>
Date: Wed Jun 25 13:26:40 2014 -0700

    virtualbox scripts translates "\r" in VM basepath

    Prevents interpretation of backslashes in output of functions
    get_vm_base_path(), get_vms_running(), get_vms_present() in
    functions/vm.sh.

    Closes-bug: #1334070
    Change-Id: I74986537e3afbae05b146d2c8c2e2262684d308e

Changed in fuel:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.