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

AutoUpdate to the version 120509x64 unpacks to the wrong folder #537

Closed
Maximus5 opened this issue Jul 31, 2015 · 17 comments
Closed

AutoUpdate to the version 120509x64 unpacks to the wrong folder #537

Maximus5 opened this issue Jul 31, 2015 · 17 comments

Comments

@Maximus5
Copy link
Owner

Originally reported on Google Code with ID 537

Required information!
OS version: Win7   SP1   x64
ConEmu version: 120509x64 (I guess the previous one)
Far version: 2.0.1807 x86



*Bug description*
The auto update from the previous ConEMU version downloads archive but unpacks it (with
WinRar) to {FAR Folder}\ConEmu.120509\...
instead of {FAR Folder}\....

*Steps to reproduction*
1.Install previous version of ConEMU
2.Execute AutoUpdate
3.Let it AutoInstall.
3. Note - there is no 7z installed, only WinRar on that machine.

Reported by saspus on 2012-05-09 22:49:40

@Maximus5
Copy link
Owner Author

WinRar works perfectly. Just tested on 4.10 beta 5 x64.

I have following default execution line in autoupdate settings:
"C:\Program Files\WinRAR\WinRAR.exe" x -y "%1"
Files was extracted to "{FAR Folder}\" as expected.

Reported by ConEmu.Maximus5 on 2012-05-09 23:10:56

@Maximus5
Copy link
Owner Author

Just received a notification about update "120509a" - I agreed and it got installed
correctly.

I will try to downgrade again tomorrow and try to reproduce the issue - it was pretty
consistent though. More info below:

The first time auto-update executed it created folder in my FAR subfolder called "ConEmu.120509"

On the next launch it offered (obviously) to update again - and created the folder
"Con.Emu.120509 (1)". The next one was with (2) in its name. Then I downloaded the
7z archive manually and copied files manually. After that, 120509a tonight installed
correctly.

I'm not sure which version of WinRar I have installed at work, will check tomorrow
and report my findings here.

Thanks,
Alex.

Reported by saspus on 2012-05-10 06:30:58

@Maximus5
Copy link
Owner Author

Ok, here we go. Today's update 120510 behaves the same way - creates a subfolder - see
the attached screenshot taken after agreeing to auto-install the update: there is an
subfolder and an invitation to download update again.


Here is more information:
WinRar version: 4.10 beta 2 (x64)

Shortcut to FAR/ConEMU: 
C:\Users\...\FAR2x86\ConEmu64.exe
start in
C:\Users\...\FAR2x86\
Run As: Administrator

Please let me know what other information do you need to troubleshoot the issue - I'll
be happy to help.

Thanks
Alex.

Reported by saspus on 2012-05-10 23:29:53


- _Attachment: Greenshot_2012-05-10_16-25-43.png
![Greenshot_2012-05-10_16-25-43.png](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-537/comment-3/Greenshot_2012-05-10_16-25-43.png)_

@Maximus5
Copy link
Owner Author

P.S. I'm running x86 version of FAR under x64 version of ConEMU started under Administrator
- it's not a typo.

Reported by saspus on 2012-05-10 23:31:25

@Maximus5
Copy link
Owner Author

You did not answer about winrar command line. Did you check it?

Also, you may try to change it manually, e.g.:
"C:\Program Files\WinRAR\WinRAR.exe" x -y "%1" "%2\"

Reported by ConEmu.Maximus5 on 2012-05-11 06:37:47

@Maximus5
Copy link
Owner Author

There was no question about command line, and yes, I did check it - it is same as yours.
"C:\Program Files\WinRAR\WinRAR.exe" x -y "%1"

I've changed it to 

"C:\Program Files\WinRAR\WinRAR.exe" x -y "%1" "%2\" 

per your comment, still same behavior.

Thanks,
Alex.

Reported by saspus on 2012-05-11 18:20:44

@Maximus5
Copy link
Owner Author

Well, it is not a problem of ConEmu. Look in _your_ WinRar options.
Report here correct arguments, when you find them.

ConEmu replaces %1 with archieve full path name, and %2 with target directory.

Reported by ConEmu.Maximus5 on 2012-05-11 18:28:45

@Maximus5
Copy link
Owner Author

Here is more infomation for you:

I've stole the "ConEmuUpdate.cmd" updater from TEMP folder and ConEmu.120510.7z payload
file. Then I played with the unpack command parameters and also played with the archive
format (e.g. I unpacked it manually and re-packed into .rar)
1. "C:\Program Files\WinRAR\WinRAR.exe" x -y "C:\<temppath>\ConEmu.120510.7z"  c:\<farpath>\FAR2x86\
   Unpacks to subfolder - failure.

2. "C:\Program Files\WinRAR\WinRAR.exe" x -ep1 -y "C:\<temppath>\ConEmu.120510.7z"
 c:\<farpath>\FAR2x86\
   Unpacks to subfolder - failure.

3. "C:\Program Files\WinRAR\WinRAR.exe" x -ep1 -y "C:\<temppath>\ConEmu.120510.rar"
 c:\<farpath>\FAR2x86\  
   Unpacks to subfolder - failure; So it is not a problem with 7z, it is problem with
WinRAR.

3. Now I tried to use UnRAR on the RAR archive - 
   "C:\Program Files\WinRAR\UnRAR.exe" x -ep1 -y "C:\<temppath>\ConEmu.120510.rar"
 c:\<farpath>\FAR2x86\  
   SUCCESS. 

So this seems to be the issue with WinRar.exe. 

As a workaround I guess you could pack update into .rar for now and use unrar until
WinRar issue is fixed. 

Thanks,
Alex.

Reported by saspus on 2012-05-11 19:06:50

@Maximus5
Copy link
Owner Author

Sorry - missed your Comment 7. There is nothing in WinRar settings that would affect
its command line behavor. At least I haven't find anything. 

Anyway, see my comment 9. This seems to be an issue with WinRar.exe, as it works fine
with UnRAR.exe.


Reported by saspus on 2012-05-11 19:12:23

@Maximus5
Copy link
Owner Author

Yeah, I've confirmed it to be WinRAR bug. 

See attached demo - check right.bat and wrong.bat and see the results.

I'll open a ticket with WinRar team

You close this ticket... but please create a workaround until winrar team fixes it.

Thanks,
Alex.

Reported by saspus on 2012-05-11 19:19:25


- _Attachment: [Rarbug.rar](https://storage.googleapis.com/google-code-attachments/conemu-maximus5/issue-537/comment-11/Rarbug.rar)_

@Maximus5
Copy link
Owner Author

Update WinRar. As I wrote, test pass on 4.10 beta 5 x64.

Reported by ConEmu.Maximus5 on 2012-05-11 19:24:01

@Maximus5
Copy link
Owner Author

I've updated WinRar to 4.20 beta 1 (64 bit) 
Fails. It also fails on my example.

Reported by saspus on 2012-05-11 19:35:14

@Maximus5
Copy link
Owner Author

I don't seem to find 4.10 beta 5 x64 installer anywhere. if you kindly share the installer
I would try with it to make sure that version also works on my machine - and that it
is not my environment issue somehow.

Thx
Alex.

Reported by saspus on 2012-05-11 19:43:26

@Maximus5
Copy link
Owner Author

You may
1. use installer for autoupdates (ConEmuSetup.exe)
2. use 7z.exe, e.g. copy 7z.exe & 7z.dll to ConEmu subfolders, and use following cmd
line
"%2\ConEmu\7z.exe" x -y "%1"

There is no other workaround can be.

Reported by ConEmu.Maximus5 on 2012-05-11 19:47:34

@Maximus5
Copy link
Owner Author

Yeah, I guess this is the way go - just wondering if other users see the same issue,
and since winrar is default unpacker in settings this may affect large number of users..

Anyway, thank you for support, we can close this case.

Regards,
Alex.

Reported by saspus on 2012-05-11 19:51:24

@Maximus5
Copy link
Owner Author

Well, I've checked newest winrar-x64-42b1.exe. Test was passed.

C:\Utils\Arch\WinRAR\WinRAR.exe x -y C:\Temp\ConEmu.120510.7z C:\Utils\Far.Test\
started in C:\Utils\Far.Test\ extracts files to C:\Utils\Far.Test\, as expected.

I believe, there is some options (in WinRAR registry key?), which cause such strange
behaviour.

Regards.

Reported by ConEmu.Maximus5 on 2012-05-11 19:56:17

  • Status changed: Invalid

@Maximus5
Copy link
Owner Author

Found it. I had a registry key 

[HKEY_CURRENT_USER\Software\WinRAR\Extraction\Profile]
"UnpToSubfolders"=dword:00000001

Removing this key fixed the issue.

I did not find yet how to change that key from UI, nor how I got this key set. 

But it does mean that ComEMU installer cannot rely on this key not being set - other
users may also have that key set as I did.


Thanks,
Alex.

Reported by saspus on 2012-05-11 20:32:17

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

1 participant