lxxgreat / roottools

Automatically exported from code.google.com/p/roottools
0 stars 0 forks source link

getSymlinks will not work on every device #14

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
getSymlinks uses the shell command "find" that is not included in androids 
toolbox (see http://forum.xda-developers.com/showthread.php?t=1163846 ) and 
thus will not work on devices without busybox.

Have we other options without relying on find?

Original issue reported on code.google.com by domschuermann@gmail.com on 28 Feb 2012 at 1:33

GoogleCodeExporter commented 8 years ago
Honestly I am not sure...Need somone that knows unix a bit better to provide 
insight into whether or not the same functionality could be done without find...

Original comment by Stericso...@gmail.com on 28 Feb 2012 at 2:34

GoogleCodeExporter commented 8 years ago
You can take the output of ls -l command and then parse it in java. I can't 
think of a better solution though

Original comment by thuanb...@gmail.com on 15 Sep 2012 at 10:54

GoogleCodeExporter commented 8 years ago
Come on, really?

if (!somefile.getAbsolutePath().equals(somefile.getCanonicalPath())) {
     // symbolic link
}

8-)

Original comment by xxx...@gmail.com on 5 Oct 2012 at 10:10

GoogleCodeExporter commented 8 years ago
Oh I almost forgot... 

http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#isSymbolicLink
%28java.nio.file.Path%29

If you are wanting something that walks a directory tree (like find does), 
there is always this:
http://docs.oracle.com/javase/tutorial/essential/io/walk.html

Original comment by xxx...@gmail.com on 5 Oct 2012 at 10:31

GoogleCodeExporter commented 8 years ago
Hahahaha, I'll add that in. I had no idea that getcanonicalPath resolved the 
symlinks.

Original comment by Stericso...@gmail.com on 5 Oct 2012 at 10:31

GoogleCodeExporter commented 8 years ago
@xxxajk: Are you sure you understand RootTools? Doing it in Java means we need 
read-access on that file in DalvikVM. 

Original comment by domschuermann@gmail.com on 6 Oct 2012 at 8:59

GoogleCodeExporter commented 8 years ago
Yes, I understand it... and if you don't got read access, you know then that 
you don't have read permissions, therefore, you can actually get permission 
info from it with a try/catch as an added bonus ;-)

Original comment by xxx...@gmail.com on 6 Oct 2012 at 12:57

GoogleCodeExporter commented 8 years ago
One other thing about the above links... Those won't apply to android 'till it 
gets the compatibility, however nothing stops us from using jni and some java 
wrapper code to provide the same thing. I don't see why we would even need to 
do some of these things via shell either, when we could simply bundle in a lib 
(.so) that could do the missing things for us and wrap it with java methods... 
If you don't know C, I do, and it would be about as easy as barrowing code 
right from busybox internals and doing a small lib. If you worry about platform 
differences (ARM/MIPS/X86/etc), that's easy to solve as well.

Original comment by xxx...@gmail.com on 6 Oct 2012 at 1:04

GoogleCodeExporter commented 8 years ago
I don't really understand your proposed method.
1. Files.isSymbolicLink is JDK 7 and not in Android
2. If you do your method from comment 3, what do you want to do if an exception 
is thrown? chmod the file to get it readable in DalvikVM?

Original comment by domschuermann@gmail.com on 6 Oct 2012 at 1:13

GoogleCodeExporter commented 8 years ago
to comment 8: We do it on a shell to get root access. A shell is opened, then 
su is executed and then you have a shell with root access where you can run 
binaries (wg busybox, toolbox).
There are some reimplementations of binaries, that comes to close to having an 
actual lib (see https://github.com/Fusion/NativeTools).

I would like to have it as a lib, but I don't see a way to get root access that 
way.

Original comment by domschuermann@gmail.com on 6 Oct 2012 at 1:17

GoogleCodeExporter commented 8 years ago
su -c dalvikvm -jar our_utility.jar some.class.that.implementsrun

Original comment by xxx...@gmail.com on 6 Oct 2012 at 4:00

GoogleCodeExporter commented 8 years ago
Just to sum up the above, incase it isn't obvious, you can use sockets to 
communicate back and forth between our_utility.jar and the app, and you can do 
many at once, thus solving the multithread problem as described in Issue 23 :-)

Original comment by xxx...@gmail.com on 6 Oct 2012 at 4:06

GoogleCodeExporter commented 8 years ago
The issue in issue 23 is not an issue with multithreading so to speak but an 
issue with how the class Shell is implemented. Currently it only hold one 
implementation of a root shell at a time. (you can see that is is held as a 
class variable and thus only one instance is allowed)

The solution to issue 23 is to allow for the instantiation of the shell class 
and to not set the rootshell as a class variable. Easy enough to do, I just 
have not had the time to complete it yet.

Also, we don't need something that walks the directory tree, since getSymlinks 
doesn't walk the directory tree anyways, at least in practice it shouldn't be 
used to do so. We could loop through every file in a directory and determine 
the symlink for each file and then build the file containing the symlinks in 
the given directory. Simply put, I used find because it was an easy way to get 
what I needed to get done...Not the most robust solution, but it did it's job.

Original comment by Stericso...@gmail.com on 6 Oct 2012 at 9:50

GoogleCodeExporter commented 8 years ago
Also, after further researching it seems to be suggested that a mismatch when 
comparing the absolute path and the Canonical Path is not a guarantee that it 
is a symbolic link (See this post here 
http://stackoverflow.com/questions/813710/java-1-6-determine-symbolic-links)

That being said, suggesting a replacement for an accurate method for a faster, 
less accurate method, seems to be ill advised based on the principle of getting 
it right the first time every time.

With that said I would have to look into this further to determine the cases 
that the mismatch would be because of something other than a symbolic link and 
what the probability of that occurring actually is. I will look into this a bit 
more and see about using the method you have mentioned.

Original comment by Stericso...@gmail.com on 6 Oct 2012 at 11:42