SAMMOUDI NAIM [ نعيم صمودي ]

Leave a comment

The difference between hard and soft links

Source :

Unix files consist of two parts: the data part and the filename part.

The data part is associated with something called an ‘inode’. The inode carries the map of where the data is, the file permissions, etc. for the data.

                               .---------------> ! data ! ! data ! etc
                              /                  +------+ !------+
        ! permbits, etc ! data addresses !

The filename part carries a name and an associated inode number.

                         .--------------> ! permbits, etc ! addresses !
                        /                 +---------inode-------------+
        ! filename ! inode # !

More than one filename can reference the same inode number; these files are said to be ‘hard linked’ together.

        ! filename ! inode # !
                         >--------------> ! permbits, etc ! addresses !
                        /                 +---------inode-------------+
        ! othername ! inode # !

On the other hand, there’s a special file type whose data part carries a path to another file. Since it is a special file, the OS recognizes the data as a path, and redirects opens, reads, and writes so that, instead of accessing the data within the special file, they access the data in the file named by the data in the special file. This special file is called a ‘soft link’ or a ‘symbolic link’ (aka a ‘symlink’).

        ! filename ! inode # !
                         .-------> ! permbits, etc ! addresses !
    '-->  !"/path/to/some/other/file"! 
                  /                      }
    .~ ~ ~ ~ ~ ~ ~                       }-- (redirected at open() time)
   (                                     }
    '~~> ! filename ! inode # !
                          '------------> ! permbits, etc ! addresses !
     '->  ! data !  ! data ! etc.
          +------+  +------+

Now, the filename part of the file is stored in a special file of its own along with the filename parts of other files; this special file is called a directory. The directory, as a file, is just an array of filename parts of other files.

When a directory is built, it is initially populated with the filename parts of two special files: the ‘.’ and ‘..’ files. The filename part for the ‘.’ file is populated with the inode# of the directory file in which the entry has been made; ‘.’ is a hardlink to the file that implements the current directory.

The filename part for the ‘..’ file is populated with the inode# of the directory file that contains the filename part of the current directory file. ‘..’ is a hardlink to the file that implements the immediate parent of the current directory.

The ‘ln’ command knows how to build hardlinks and softlinks; the ‘mkdir’ command knows how to build directories (the OS takes care of the above hardlinks).

There are restrictions on what can be hardlinked (both links must reside on the same filesystem, the source file must exist, etc.) that are not applicable to softlinks (source and target can be on seperate file systems, source does not have to exist, etc.). OTOH, softlinks have other restrictions not shared by hardlinks (additional I/O necessary to complete file access, additional storage taken up by softlink file’s data, etc.)

In other words, there’s tradeoffs with each.

Now, let’s demonstrate some of this…

ln in action

Let’s start off with an empty directory, and create a file in it

~/directory $ ls -lia 
total 3
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:16 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..

~/directory $ echo "This is a file" >basic.file

~/directory $ ls -lia 
total 4
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:17 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..
  73478 -rw-r--r--   1 lpitcher users          15 Mar 11 20:17 basic.file

~/directory $ cat basic.file
This is a file

Now, let’s make a hardlink to the file

~/directory $ ln basic.file hardlink.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 hardlink.file

~/directory $ cat hardlink.file
This is a file

We see that:

  1. hardlink.file shares the same inode (73478) as basic.file
  2. hardlink.file shares the same data as basic.file

If we change the permissions on basic.file:

~/directory $ chmod a+w basic.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file

then the same permissions change on hardlink.file.

The two files (basic.file and hardlink.file) share the same inode and data, but have different file names.

Let’s now make a softlink to the original file:

~/directory $ ln -s basic.file softlink.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:24 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file
  73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

~/directory $ cat softlink.file
This is a file

Here, we see that although softlink.file accesses the same data as basic.file and hardlink.file, it does not share the same inode (73479 vs 73478), nor does it exhibit the same file permissions. It does show a new permission bit: the ‘l’ (softlink) bit.

If we delete basic.file:

~/directory $ rm basic.file

~/directory $ ls -lia 
total 4
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:27 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   1 lpitcher users          15 Mar 11 20:17 hardlink.file
  73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

then we lose the ability to access the linked data through the softlink:

~/directory $ cat softlink.file
cat: softlink.file: No such file or directory

However, we still have access to the original data through the hardlink:

~/directory $ cat hardlink.file
This is a file

You will notice that when we deleted the original file, the hardlink didn’t vanish. Similarly, if we had deleted the softlink, the original file wouldn’t have vanished.

A further note with respect to hardlink files

When deleting files, the data part isn’t disposed of until all the filename parts have been deleted. There’s a count in the inode that indicates how many filenames point to this file, and that count is decremented by 1 each time one of those filenames is deleted. When the count makes it to zero, the inode and its associated data are deleted.

By the way, the count also reflects how many times the file has been opened without being closed (in other words, how many references to the file are still active). This has some ramifications which aren’t obvious at first: you can delete a file so that no “filename” part points to the inode, without releasing the space for the data part of the file, because the file is still open.

Have you ever found yourself in this position: you notice that /var/log/messages (or some other syslog-owned file) has grown too big, and you

     rm /var/log/messages
     touch /var/log/messages

to reclaim the space, but the used space doesn’t reappear? This is because, although you’ve deleted the filename part, there’s a process that’s got the data part open still (syslogd), and the OS won’t release the space for the data until the process closes it. In order to complete your space reclamation, you have to

     kill -SIGHUP `cat /var/run/`

to get syslogd to close and reopen the file.

You can use this to your advantage in programs: have you ever wondered how you could hide a temporary file? Well, you could do the following:

        FILE *fp;

        fp = fopen("some.hidden.file","w");
        unlink("some.hidden.file"); /* deletes the filename part */

        /* some.hidden.file no longer has a filename and is truely hidden */
        fprintf(fp,"This data won't be found\n"); /* access the data part */
        fclose(fp); /* finally release the data part */

Leave a comment

Improving Android App Quality

With thousands of new apps being published in Android Market every week, it’s becoming more and more important to proactively work at breaking through the clutter (hooray for marketing jargon!). One way of improving your app’s visibility in the ecosystem is by deploying well-targeted mobile advertising campaigns and cross-app promotions. However, there’s another time-tested method of fueling the impression-install-ranking cycle: improve the product!

A better app can go a very long way: a higher quality app will translate to higher user ratings, generally better rankings, more downloads, and higher retention (longer install periods). High-quality apps also have a much higher likelihood of getting some unanticipated positive publicity such as being featured in Android Market or social media buzz.

The upside to having a higher-quality app is obvious. However, it’s not always clear how to write a so called ‘better app.’ The path to improving app quality isn’t always well-lit. The term ‘quality’, and its close cousins ‘polish’ and ‘fit and finish’ aren’t always well-defined. In this post, we’ll begin to light the path by looking at a couple of key factors in app quality, and furthermore, look at ways of improving your app along these dimensions…

If you’re a developer it’s a good resource if you’re new to the game and need somewhere to start. Go ahead and check it out now at the Android Developers blog.

Leave a comment

Why Android App security is better that iPhone

Application security has become the focus of a flurry of intense attention in the mobile world lately, due largely to a few well-publicized events affecting each of the major platforms.

On the iPhone side, of course, there’s the JailbreakMe tool, which unlocks the device’s operating system in a way that could potentially be emulated by malicious applications.

On the Android side, it’s been the case of the data-accessing wallpaper apps–which, it turns out, did not do anything to put users at risk after all.

Transmission security, meanwhile, has given theBlackberry platform its own share of the limelight in data-monitoring nations.

Yet, while it’s clear no mobile platform has perfect security–nor is that even possible–Android has a number of compelling advantages that make its apps inherently safer than those for the iPhone.

1. Application Permissions

On the Linux-based Android platform, each application runs in a separate “silo,” unable by default to read or write data or code to other applications. Associated with each isolated application is a unique identifier and a corresponding set of permissions explicitly governing what that particular application is allowed to access and to do.

As a result, much the way Linux users typically don’t have “root” privileges with the associated power to do systemwide harm, so Android apps by default are limited in a similar way. Just as Linux minimizes the damage that could be done on the desktop by a virus affecting an individual user, in other words, so Android restricts the potential damage that could be done by a rogue application.

In order for any data to be shared across Android applications, it must be done explicitly and in a way that informs the user. Specifically, before installation can even happen, the app must declare which of the phone’s capabilities or data it will want to use–the GPS, for example–and the user must explicitly grant permission to do so. Those wallpaper apps, it should be noted, were no exception. So, if a user sees upon installation that a simple wallpaper app is requesting access to her list of contacts, say, there’s probably reason to think twice before proceeding.

On the iPhone, on the other hand, it’s a different story. All apps are considered equal and can access many resources by default, and without having to tell the user. So, while on Android you’ll be able to see that a malicious app is suspicious the moment you try to install it, on the iPhone iOS, you’ll have no idea–potentially until the harm is done.

2. App Markets

Whereas Android puts the user in control of evaluating an application’s requirements before it installs, Apple keeps that control for itself. Instead, like an overprotective parent, it insists on approving each and every application before it can be offered up for sale in theApp Store–part of its strategy of maintaining the iPhone platform’s “walled garden.”

In the Android Market, of course, there are no such restrictions–again, it’s up to users to evaluate the apps they buy upon installation.

While some view Apple’s approach as the safer one for users, the opacity of its process makes it unclear what, exactly, the company checks on incoming applications. Given the sheer number of new apps written every day, it seems unlikely that Apple–or any company–could do more than simply verify the developer’s identity and make sure the app does what it promises to do. It would also be easy for any developer to add malicious code after an app has been approved.

Either way, there’s no doubt that plenty of apps that Apple had vetted later were found to have vulnerabilities. Just recently, security research firm Lookout found that applications on Android are generally less likely than those for the iPhone to be capable of accessing a person’s contact list or retrieving their location. It also found that nearly twice as many iPhone apps can access the user’s contact data.

3. Openness

Although the Android platform isn’t as open as many would like it to be, there’s no denying that it is far more open than Apple’s iPhone platform is. Among the many benefits of that openness is that the code underlying the platform is available for scrutiny by users and developers the world over. I don’t care how many people Apple’s team has; there’s no way their number could compete with that. The result? More “eyeballs” studying the code means problems are caught more quickly.

In this era of transparency and participation, I believe that openness and user control are what’s needed in the rapidly expanding mobile world. No single company, however capable it might be, can protect users from everything. Nor, indeed, should any single company be entrusted with such a responsibility. The far better approach is to give users a way to play a role in monitoring security themselves, and that’s just what Android does.

Leave a comment

Google Wants Your Grandma Building Android Apps !

The Android App Marketplace is growing at a steady pace, but Google wants to get as many apps as possible, maybe in an effort to catch up to Apple, and has now introduced the Google App Inventor which enables practically everyone to create a mobile app for the Android platform.

The idea behind App Inventor is simple, creating applications is hard work, even those based on standard web technologies, and requires knowledge outside the reach of most people. While anyone with some programing experience can put together a basic app in a matter of hours, the way Google sees it, your grandma should be able to build Android apps as well.

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

According to the AppInventor team they :”created blocks for just about everything you can do with an Android phone, as well as blocks for doing ‘programming-like’ stuff– blocks to store information, blocks for repeating actions, and blocks to perform actions under certain conditions. There are even blocks to talk to services like Twitter.”

The blocks editor uses the Open Blocks Java library for creating visual blocks programming languages. Open Blocks is distributed by the Massachusetts Institute of Technology’s Scheller Teacher Education Program and derives from thesis research by Ricarose Roque. We thank Eric Klopfer and Daniel Wendel of the Scheller Program for making Open Blocks available and for their help in working with it. Open Blocks visual programming is closely related to the Scratch programming language, a project of the MIT Media Laboratory’s Lifelong Kindergarten Group.

The compiler that translates the visual blocks language for implementation on Android uses the Kawa Language Framework and Kawa’s dialect of the Scheme programming language, developed by Per Bothner and distributed as part of the Gnu Operating System by the Free Software Foundation.

The App Inventor for Android build apps using a web browser and a Java Web Start application. The development team notes that it is compatible with Mozilla Firefox 3.6 and higher, Apple Safari 5.0 and higher, Google Chrome 4.0 and higher, and Microsoft Internet Explorer 6 and higher, and that it can be used on computers running under Windows (XP, Vista and 7), Mac OS X 10.5, 10.6, or Linux (Ubuntu 8+, Debian 5+). Java 6 is also required. Additional details on the matter are available here.


Leave a comment

Apple versus Android !

Voici une image qui résume, assez bien les différences entre iPhone OS et Android aujourd’hui pour les développeurs (et qui reflète aussi les différences de mentalité entre les deux systèmes : fermé et ouvert) :

L’auteur a toutefois oublié que pour publier sur l’Android Market il en coutait 25 dollars.

source: frandroid

Leave a comment

Quel avenir pour Android ?

Selon un  sondage sur les prochains produits Android hors smartphone. La plupart ont répondu sur 4 axes : Tablettes Intenet (22%), GPS autonomes (18%), Automobile embarquée (15%) et Baladeurs MP3 (13%).

Ce résultats sont assez peu surprenant pour les 2 premiers. En effet, la voie a été ouverte sur différents MID avec Archos par exemple. Ils prendront d’ailleurs cette forme ou une forme dérivée comme les cadres photos. Les navigateurs GPS ne sont pas étonnants également. Avec peu de modifications, un téléphone actuel se transformera en GPS autonome simple avec des logiciels qui existent déjà (voir le test de CoPilot Live).

Plus étonnant est l’embarquement d’Android dans les voitures. Ils été 15% à y croire. C’est loin d’être improbable puisque Wind River y travaille, Parrot OEM s’y investi et Tesla l’intègre sur son modèle S. Il y a donc de fortes chances de voir Android débarquer au sein des voitures avec des fonctionnalités nouvelles et spécialement adaptées à l’automobile.

Il faudra tout de même observer l’évolution d’Android. L’arrivée de Chrome OS aura une influence. Certains bruits laissent penser à un fort rapprochement entre les 2 OS. Un autre bruit plus discret, est celui d’une prise de recul de Google par rapport à Android pour laisser les constructeurs plus autonomes. Cela leur donneraient plus d’air pour développer le système à leur guise, mais le revers de la médaille sera alors moins beau.

Les produits fonctionnant sur Android en 2010 arriveront vraiment à nous étonner et seront aussi ailleurs que les smartphones. C’est une certitude !

Reste à savoir quand le “leader mondial des produits haut débit” ,sagemcom,   aura une pensé pour bénéficier des services de l’humanoïde de Google, et de son “Bazar” . Sachant qu’il vient de commercialiser son nouveau né T-Hub tablet phone . Qui a mon avis aura des difficultés à suivre la cadence qui sera imposé par les produits concurrents à base d’android avec toute ses applications et le support de la communauté , surtout après le rapprochement de Google avec Linux Foundation( consortium à but non lucratif  qui a pour mission de protéger et standardiser Linux) .

Ce rapprochement devrait permettre à Android de faire un pas de plus vers la reconnaissance comme un système linux à part entière (avec le côté open source validé).

source :

<object width=”400″ height=”230″><param name=”allowfullscreen” value=”true” /><param name=”allowscriptaccess” value=”always” /><param name=”movie” value=”;;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1&#8243; /><embed src=”;;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1&#8243; type=”application/x-shockwave-flash” allowfullscreen=”true” allowscriptaccess=”always” width=”400″ height=”230″></embed></object><p><a href=”″>Tesla Model S hands-on</a> from <a href=””>Ryan Block</a> on <a href=””>Vimeo</a&gt;.</p>

1 Comment

QEMU Emulator, Arriba Tools for QEMU and Android Native Development Kit Available Free-of-Charge

Android was originally developed by Google and the Open Handset Alliance (OHA) for mobile applications. It is a software stack that includes Linux, middleware and key applications code. Android applications are written in Java and to support development, the OHA created both the software development kit (SDK) and Android development kit (ADK). These development kits are available at no charge and are ideal if your application is a handset.

Android Application Development with the New Arriba APK from MIPS Technologies

Now available from MIPS Technologies and created through our partnership with Viosoft Corporation, is the Arriba for Android Porting Kit (APK) for the industry-standard MIPS® architecture. The Viosoft Arriba Debugger is bundled with the Arriba APK and is the centerpiece of the kit. It is far more powerful then the original ADK, providing debug access from the Linux kernel to Android application Java code. The original ADK is limited to debugging Java code only, greatly restricting an engineer’s ability to debug real-world Android applications.

Arriba APK

Many companies are looking to extend Android to non-mobile devices such as iPTV, DVD, set-top boxes and Mobile Internet Devices (MIDs). The MIPS architecture is very popular in these markets, and to support these development efforts, Viosoft Corporation and MIPS have joined forces to offer the Arriba Android Porting Kit for MIPS processors.

Android Development Challenges for Non-Mobile Applications

In the initial deployment of Android, libraries and middleware are specific to the ARM processor architecture. This is to be expected since ARM is widely deployed in the majority of mobile handsets, the original Android target market. However, retargeting Android for other markets beyond the mobile handset means Android must support other popular embedded processor architectures like MIPS.

To successfully develop Android applications for non mobile platforms, developers must be prepared to debug a mix of Java and C/C++ code. This is because Android Java libraries and middleware use the Java Native Interface (JNI) frequently to invoke C/C++ code in shared libraries. The original Android developers warned third party developers against using these programming practices, but to extend Android to non-mobile applications, this is exactly the kind of code that software engineers must develop and debug.

The Arriba APK is designed to help software developers and ODMs/OEMs overcome these programming challenges and bring new Android-based products to market. It includes:

  • A complete cross development environment and a reference Linux kernel distribution to help developers prepare their platforms for Android-readiness
  • A port of Android to selected embedded platforms that the customers can use as a working reference, or a starting point that can be refined toward their final design
  • The Arriba debugger, which provides visibility into all layers of a running Android system to help developers pinpoint difficult bugs in C/C++ middleware or even kernel drivers
    • The Arriba debugger does not require any kernel patches or instrumented code—enabling it to work on applications already deployed to the field
    • Unlike the original ADK, which can only debug Java application code, the Arriba debugger supports debugging Java code all the way down to the Linux kernel: true “top to bottom” debug
  • The APK includes five MIPS System Navigator™ EJTAG probes to support hardware bring-up, Linux kernel debug and low-level Android debug
    • The Arriba debugger can also connect to the target system via an Ethernet, USB or serial port
    • The EJTAG probes include a one year warranty
  • To help ensure success, the Arriba APK include 60 days of Android porting support. This is intensive hands-on support, helping to ensure that you get Android successfully ported to your hardware

The Arriba Android Porting Kit contains everything a development team will require to successfully deploy Android applications on the MIPS architecture for mobile and non-mobile applications.