12 Replies Latest reply on May 6, 2008 8:00 AM by Lioshyi

    A bug?

    Lioshyi
      Guys, I have a small issue.

      var newDir:File = File.desktopDirectory.resolvePath("../..");
      newDir.nativePath; is "C:\\Documents and Settings\\USERNAME"

      var newDir:File = File.desktopDirectory.resolvePath("../..");
      newDir.nativePath; is "C:\\Documents and Settings"

      but when I'm using File.applicationDirectory results are different from expected.
      var newDir:File = File.applicationDirectory.resolvePath("..");
      newDir.nativePath; is "C:\\Documents and Settings\\USERNAME\\My Documents\\Flex Builder 3\\AirApp\\bin-debug"

      var newDir:File = File.applicationDirectory.resolvePath("../..");
      newDir.nativePath; is "C:\\Documents and Settings\\USERNAME\\My Documents\\Flex Builder 3\\AirApp\\bin-debug"

      the same situation with installed App.
      I'm doing something wrong? If yes please let me know where mistake is.
      Thanx
        • 1. Re: A bug?
          duncanhall Level 1
          What is it you are actually trying to do?

          If you are simply trying to get the path of the application directory:

          var appDirPath:String = File.applicationDirectory.nativePath;
          • 2. Re: A bug?
            Lioshyi Level 1
            I'm trying to go out of app's dir.
            I have my app installed to "c:\Program Files\AirApp\" .I want to rich "c:\Program Files\" using ".." and create there another dir and I don't want to use "c:\Program Files\" hardcode.
            • 3. Re: A bug?
              Oliver Goldman Adobe Employee
              No, this is not a bug. The File.applicationDirectory is scoped to just the application itself and relative navigation out of this location is deliberately disallowed. This is done in part to avoid bugs in which code that should be reading only application resources might accidently reach outside of that directory and inadvertently reference something else.

              Regardless, you should not author your application to try and create directories inside c:\Program Files because that's a protected location. Writing there will sometimes work, but often--in enterprise deployments, and on Vista by default--it will not.

              Oliver Goldman | Adobe AIR Engineering

              • 4. Re: A bug?
                I for one dont like these kind of imposed restrictions when the OS iteself is responsible for user access.
                E.g. what happens if the user choses to install all AIR apps in an area that is non-protected? Why should AIR then disallow read or write access?
                At the end of the day, this imposed restriction of not allowing resolvePath from applicationDirectory seems even stranger. For example its not that AIR is actually not allowing read or write to for example the parent directory, just it wont let you resolvePath. Soo strange.
                As a simple workaround you can get the nativePath and strip last directory component off in code. Something like:
                var path = File.applicationDirectory.nativePath;
                var parentPath = path.substr(0,path.lastIndexOf("\\"));


                Madness
                • 5. Re: A bug?
                  Dr. Fred Mbogo Level 1
                  Finer granularity in the protection model would be nice, but I'm glad Adobe's stepped up and provided reasonably secure defaults. AIR apps are going to be used on regular end user systems, and most of these are horribly insecure. Yes, the various OSes in use all have reasonable facilities for adding proper protection, but most users bypass them, which is why 50% of the software in your typical OfficeMax is antivirus, firewall, antispyare, spam filtering, and content filtering.

                  Think about that for a sec. Half the software is devoted to things which don't get real work done. It's devoted to keeping the machine from being overwhelmed so you can actually use the other 50% of the software. That's sad. Very sad. It's long past time we started pushing that number back towards 1%, where it belongs.
                  • 6. Re: A bug?
                    jkhgdkhgslkj, I think you misunderstand the security model/protection in AIR.
                    1) There is nothing stopping an AIR app delete all a users files or all of the c drive (OS permissions dependent)
                    2) this specific resolvePath issue/bug also offers no protection as its easily coded round.

                    Hence any "protection" offered by AIR is simply fake. So why have it at all.
                    • 7. Re: A bug?
                      Dr. Fred Mbogo Level 1
                      v1.0
                      • 8. Re: A bug?
                        Are you suggesting we shouldnt discuss as its v1.0???
                        • 9. Re: A bug?
                          Oliver Goldman Adobe Employee
                          Preventing resolution outside of File.applicationDirectory isn't to protect the user; as j.t.g. points out, you can still access the entire filesystem. It's to protect the developer from inadvertently loading code from outside the application's directory into the application's security sandbox when they almost certainly didn't mean to do that.

                          Furthermore, note that we don't absolutely prevent you from loading arbitrary code into the application sandbox. Our goal is just to prevent developers from inadvertently doing dangerous things that could compromise their application. Developers who are comfortable with the risk and wish to take it on for themselves can still do so.

                          regards,
                          Oliver Goldman | Adobe AIR Engineering

                          • 10. Re: A bug?
                            Dr. Fred Mbogo Level 1
                            quote:

                            Originally posted by: j.t.g.
                            Are you suggesting we shouldnt discuss as its v1.0???


                            Adobe has made some clear signals that they intend to offer optional lock-down features in future versions of AIR. You will be able to opt out of some of the freedoms you have in AIR 1.0, and this will be reflected in the AIR installer, so the user knows your program will not do certain things, like writing to random locations on the hard drive. Today, the programmer can affect only one of the two security indicators in the AIR installer: using a registered code signing certificate turns one of the two normally-red indicators green. The ability to affect the other indicator will come next.
                            • 11. Re: A bug?
                              quote:

                              Originally posted by: jkhgdkhgslkj
                              ... The ability to affect the other indicator will come next.


                              I dont care about the indicators. I do care about an arcane security model though!
                              The sandbox restrictions make it impossible to create certain applications and this particular thread shows what appears is a bug yet has actually been designed that way.
                              I agree v1.+ will change some sandbox/security things, I just hope for the better.

                              • 12. Re: A bug?
                                Lioshyi Level 1
                                Thanks all for posting. It seems I've got the idea.