How to use reuse softlinks created on Mac in Windows 8

Question

I have few softlinks, says 1000 images which i have created in MacBook Pro which i am using in my iOS Apps.

Now i am porting the same app in Windows 8 phone app, so

Answer 1

I know I am late in this, but I hope that others may benefit from my answer, even though the asker may long have moved on.

Some background

Symbolic link semantics differ considerably between unixoid systems and Windows. As was stated before, Windows uses reparse points to implement symbolic links and junction points (some deduplication features on the Server editions also seem to use it).

Now, a reparse point contains extra data as a hint to the I/O manager and object manager. Essentially, based on a reparse point tag (a GUID) the type of reparse point can be determined and then a file system filter driver handles the details. You can find a moderately detailed description of this in the 6th edition of "Windows Internals" in chapter 9 or in a recent Windows Driver Kit or on MSDN under REPARSE_GUID_DATA_BUFFER (and related topics).

On unixoid systems the file system metadata also contains a clue that the (text file) is a symlink. If you use ls -l that clue is visible in the form of a leading l, e.g. in:

lrwxrwxrwx  1 user group         38 2015-10-12 11:51

The actual contents of symlinks are system-specific as well, on Linux for example they contain merely the target path.

What the Windows and *nix symlinks share is that the target needn't exist at the time of creation. Also on Windows a symlink can point to a network location, which is special because on Windows network paths differ from local paths.

Possible compatibility

Assuming a symlink was created on the OSX or Linux side, we can imagine certain levels of compatibility. If the file system driver on the Windows side would now present symlinks as reparse points and some party (either said file system driver or a file system filter) would handle these reparse points, it would be possible to interpret the target path of a symlink in some way.

Converting forward slashes to backward slashes is the least concern, however.

In this answer I already outlined a few cases where there would be no meaningful translation possible.

Essentially the only type of symlinks for which I would see a potential for compatibility are relative symlinks. But even for those is is necessary to point out that the target path may not point outside of the folder hierarchy that is visible on the Windows side. That is, if your symlink on the OSX or Linux side resides inside /var/www/html and points to ../../../something it becomes meaningless in a case where /var is the mounted volume on Windows.

If, however, such symlink /var/www/html/foobar and pointed to ../html1/foo/bar chances are that if /var was the mounted volume on OSX or Linux and now on Windows, the relative target path still makes sense (after adjustments such as forward to backward slashes etc).

For any absolute target paths, the file system driver or the file system filter driver would have to get some hints on how to translate the source form of a symlink into the target form.

E.g. if a symlink pointed to /home/foo/bar the /home part might translate to a specific mounted volume.

But you can already see that this requires a lot of user intervention, which is probably why most people would consider it futile to even attempt a meaningful translation.

Possible workaround for SVN

A possible workaround for you could be to use SVN externals. It depends on the exact scenario, but since you are using SVN they come to mind.

You can think of SVN externals as Subversion's native symlinks. I have used them this way and I know of several others who have, but I don't know how widespread that train of thought and subsequent usage is.

Attention: externals pointing to files were only introduced in SVN 1.6, so this may or may not be an issue in your scenario.

SVN externals come in several flavors. You can set them for folders or files (files only with 1.6 and newer).

And an external can point to:

1. an external repo (schema://server/path)
2. relative to the same repo (^/path)
3. relative to the schema (//server/path) or
4. relative to the parent directory

You'll probably want 2 or 4 from that list. Most likely you'll want 4, though, because file externals must point to the same repository.

Long story short

If your images are in a folder such as trunk/images and you have a folder trunk/platforms/windows/images you can either set the the svn:externals property on trunk/platforms/windows to have an external named images pointing to ../../images (i.e. directory external) or, assuming you wanted to use a different hierarchy or different names underneath trunk/platforms/windows/images you could create file externals like so (images subdirectory must exist in WC):

cd trunk/platforms/windows
svn propedit svn:externals images

and add individual externals like this:

../../../images/filename.jpeg other-filename.jpeg

Please note that the target directories need to exist in the repository and the working copy, so for an external like this:

../../../images/filename.jpeg foo/other-filename.jpeg

the subdirectory trunk/platforms/windows/images/foo must exist.

Updating your working copy will result in those externals to manifest as versioned files inside the working copy. So they are a type of symlinks that exists in SVN and manifests as proper files in the working copy, which means all platforms can handle them equally.