Would you like to replace the existing file was asked while extracting selenium-server-standalone jar file - selenium

After having downloaded the selenium-server-standalone-3.141.59 jar file from https://www.selenium.dev/downloads/, I tried to extract the files. During the extraction, a pop-up shows up saying:
"The following file already exists. C:\Selenium3\selenium-server-standalone-3.141.59\META-INF\LICENSE.txt
Would you like to replace the existing file [file 1 with 11.969 bytes modified on 02/11/2014 19:52] with this one [file 2 with 36.116 bytes modified on 25/04/2013 16:52]"
I then get to choose from options like 'Yes', 'Yes to all', 'No', 'No to all' etc. Why is this happening? I was expecting a normal extraction in which all files are simply extracted and no questions asked about whether to replace certain files or not. Is there a bug with this jar file?
Please see attached screenshot.

I was able to reproduce the error...
while trying to extract the contents of selenium-server-standalone-3.141.59.jar.
Solution
If your usecase is to use selenium-server-standalone-3.141.59.jar within a Java project, instead of extracting the selenium-server-standalone-3.141.59.jar you need to add the jar file as an External JAR in the JAVA BUILD PATH for your project within the IDE as follows:

Related

How to extract .sql file that seems to be a .zip

I have received a file from a customer. The file is said to be
SQL code (application/sql)
However, this has turned out to be wrong: nothing could open it. It turns out it was secretely a .zip file. By renaming it to '.zip' and manually extracting it I was able to get the files contained in it. I would like to do a similar process in python.
So far I've renamed the file:
file_name_zip = file_name.replace('.sql', '.zip')
os.rename(file_name, file_name_zip)
And I've tried extracting it:
zip_ref = zipfile.ZipFile(file_name_zip, 'r')
zip_ref.extractall(extracted_file)
However, this failed because
zipfile.BadZipFile: File is not a zip file
I've googled, and apparently this can sometimes be fixed using:
zip_file_name_2 = zip_file_name.replace('.zip', '2.zip')
os.system(f'zip -FF {zip_file_name} --out {zip_file_name_2}')
This required me to put in a bunch of settings, which I wasn't able to figure out. There must be a better way to go about this.
Does anybody know how to parse such an .sql file?

How to copy a scala source file to same directory (with different name) from Intellij explorer

From the screenshot below: I did a command-C copy of a scala source file - seen in the screenshot as BpmSpecs . Then went to the containing folder eventapi , right clicked and selected paste.
Well .. Intellij did a rather boneheaded thing here: it created a new directory called .. wait for it .. LocalEngineCycles.scala .. and proceeded to copy the original file into that directory under the same name as the original file.
So .. how to copy a scala source file into the same directory - and having intelllij actually help us by allowing us to supply the new filename ?
Re: possible duplicate: it is not. This problem relates to a File. I clone classes successfully all the time: IJ asks me to change the ClassName and I do it. For the file it gets confused and instead creates a new directory and places a copy of the original file inside this new directory.

Current file path in Live Template

Is it possible to get the full path of the current file within a live template in IntelliJ? I've tried using groovyScript("new File('.').absolutePath") function, but that returns /Applications/IntelliJ IDEA.app/Contents/bin/. and not the file path as I was hoping for.
Thanks!
According to the docs (emphasis mine):
You can use groovyScript macro with multiple arguments. The first argument is a script text that is executed or a path to the file that contains a script. The next arguments are bound to _1, _2, _3, ..._n variables that are available inside your script. Also, _editor variable is available inside the script. This variable is bound to the current editor.
The _editor is an instance of EditorImpl which holds a reference to the VirtualFile that represents the currently opened file.
Therefore, the following script gets the full path of currently opened file.
groovyScript("_editor.getVirtualFile().getPath()")
Or if you want to get the path relative to the project's root:
groovyScript("_editor.getVirtualFile().getPath().replace(_editor.getProject().getBaseDir().getPath(), \"\")")
Since IntelliJ IDEA 2019.3 the Live Template macros filePath() and fileRelativePath() are available. A complicated Groovy script macro is no longer required.

finding a corrupted part from the parts of a split archive

I have 7 files with extensions like xyz.rar.001 - xyz.rar.007 clearly they are parts of a single file. I have all the 7 parts. I join them using a file joiner into a single file xyz.rar and try to unrar them with WINRAR , it says that archive is corrupted It is clear that 1 or 2 parts are corrupted. IS THERE ANY WAY TO FIND THEM ? Please help I don't want to re download all of them NOTE- winrar can detect a corrupt part if the parts were splitted using winrar (with extensions like part1.rar , part2.rar etc. ) but not if they are named as rar.001
Parts .001 - .006 should have the same size. Check if there is a file with a different byte size.
Are there multiple files in the RAR or just the one? With multiple you could run a Test and see which is the first file to fail.
I think it's strange that there is a second tool used to split the RAR archive up. (e.g. HJSplit) This lets me think that .002 could be a RAR archive too. Try opening xyz.rar.001 with WinRAR and test/exctract. It happens more that RAR archives have the extension .001 instead of .rar. An example.
Naming your archives in WinRAR like this can be accomplished by putting "xyz.rar.001" as Archive name on the General tab and checking "Old style volume names" on the Advanced tab.
If I then join the files with HJSplit, I get one .rar file (that is corrupt). When I Test it, it says "Next volume is required". In the diagnostic messages I can see "The required volume is absent" and "CRC failed in X. The file is corrupt"
If there is one file stored inside the RAR and the RAR is indeed just chopped up into 7 pieces, there is no way of telling without additional files such as .sfv or .par2. (unless the RAR does not use compression: you can parse the underlying file for errors and calculate the part where it goes wrong)

Why .RAR file contains different files with the same name

I got a .RAR file which contains different files with the same name.
For example,
index.txt 40 Text Document 04/01/2010 4:40PM
index.txt 22 Text Document 04/01/2010 4:42PM
index.txt 10 Text Document 04/01/2010 4:45PM
index.txt 13 Text Document 04/01/2010 4:50PM
Why?
Like said before, the files could be in separate paths, but as I'll show further, this isn't always the case.
If you use WinRAR to list the file contents and your options are set as the following, then it only appears you have files with the same name, but they are in different paths.
Options -> File list -> Flat folders view (ctrl+h)
Options -> File list -> Details
After the column CRC32, there is one called Path. If this is different, extraction shouldn't be a problem if:
Extract -> Extraction path and options -> Advanced -> Extract relative paths is set.
If it is Do not extract paths, WinRAR will need to ask you to rename them because of file system limitations.
I assume command line unrar won't be a problem in this case because you need to specify additional parameters to change its default behavior.
It is possible for a RAR archive to have multiple files with the same name in the same directory. If you use Windows, use "C:\Program Files\WinRAR\Rar.exe"
instead of rar on the command line in the following examples.
Create a new file and add it to a RAR archive. You can also check the changes by listing its contents.
rar a rarfile.rar testfile.txt
rar l rarfile.rar
rar a rarfile.rar testfile.txt
If you try to re-add this file, rar will replace the already added file with the same name.
Updating archive rarfile.rar
Updating testfile.txt OK
Done
Create an other file or rename the first one and add it to the RAR file.
move testfile.txt second.txt (new file)
rar a rarfile.rar second.txt (add it)
rar lb rarfile.rar (list archive, bare info)
Rename the second file to the first one's name.
rar rn rarfile.rar second.txt testfile.txt
This is how you create a RAR file with multiple files of the same name in the same path. These steps will be similar in WinRAR. If you try to rename the file again, the file name of all files in that directory will change too.
Why would someone want to do this?
The only explanation I can think of is that the person that created this archive wanted to imitate a version control/backup system. But if you want to extract only one specific version and it isn't the first one, WinRAR extracts the wrong file. It seems I've found a very obscure WinRAR bug :-)
Edit: seems a bad explanation after finding this in the RAR documentation:
-ver[n] File version control
Forces RAR to keep previous file versions when updating
files in the already existing archive. Old versions are
renamed to 'filename;n', where 'n' is the version number.
By default, when unpacking an archive without the switch
-ver, RAR extracts only the last added file version, the name
of which does not include a numeric suffix. But if you specify
a file name exactly, including a version, it will be also
unpacked. For example, 'rar x arcname' will unpack only
last versions, when 'rar x arcname file.txt;5' will unpack
'file.txt;5', if it is present in the archive.
If you specify -ver switch without a parameter when unpacking,
RAR will extract all versions of all files that match
the entered file mask. In this case a version number is
not removed from unpacked file names. You may also extract
a concrete file version specifying its number as -ver parameter.
It will tell RAR to unpack only this version and remove
a version number from file names. For example,
'rar x -ver5 arcname' will unpack only 5th file versions.
If you specify 'n' parameter when archiving, it will limit
the maximum number of file versions stored in the archive.
Old file versions exceeding this threshold will be removed.
they are in different paths, most likely.
try outputting the full path. or see what happens when you extract them.
you'll probably see something like:
index.txt
path1/index.txt
path2/index.txt
etc etc