How to use reuse softlinks created on Mac in Windo

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 i want to reuse the same Softlink in Windows phone 8 apps as well, so how can i use that ?

I have tried to open the softlink in Windows 8 machine, but it says that the "File format is not supported".

I have both the original file and the softlink in my Windows machine.

Is there anyother way that i can reuse the same soft link ? if NOT what is the best approach that i can follow.

EDIT

Ok, here is some more info on this :

In MacBook Pro

I have a folder in desktop which has physical paths (actual images), now i have created softlinks using a script and these softlinks are placed in some different folder.

Now i am using these soflinks in my iOS app.

In Windows 8

I have copied the folder which has soflink as well as the folder which has actual files in it from Mac.

Now i have pasted actual files folder on my desktop and soflinks folder in some D: drive now if i go my soflink folder in D drive and when i check those images it shows blank, because its not pointing to the actual files.

I have both actual files folder and also the soflink folder.

One more point is that when you create a soflink, in MacBook Pro it shows this icon :

But on Windows 8 its blank nothing like that.

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.

Answer 2

Maybe the problem is that there are so many links in one directory

There is a maximum of 31 reparse points (and therefore symbolic links) allowed in a particular path.

See also

• Programming Considerations

Answer 3

Your question is missing a couple of details so I'm going to have to make a guess about your situation. The problem is:

You created some symlinks using OS X on a file system and now you are having problems accessing those symlinks in Windows.

Unless you did something tricky, like installing 3rd party file system drivers, then the only file system that both Windows and OS X can read/write to natively is FAT based. So I'm guessing your situation is:

You created some symlinks using OS X on a FAT32 file system and now you are having problems accessing those symlinks in Windows.

Assuming the above situation, the problem is that there are no symlinks in FAT32 because the file system doesn't support them. OS X is tricking you because it "just works". What is really happening is that OS X is creating an ASCII text file that contains the line "XSym" along with the name of the file it is "linking" to, plus some file system information. You can confirm this by opening your softlinks on your Windows system in notepad. Normally you would see binary code if you were opening an actual image in notepad, but instead you should see the text from these fake symlinks.

So, what do you do? I see a couple of options:

1. You could use a file system that supports soft links. This could mean using HFS+ (OS X file system) which would require you to install HFS+ drivers on your Windows system so that it can read/write to the file system. Or it could mean going in the other direction and using NTFS (Windows file system) which would require you to install NTFS drivers on your Mac. Note that most recent versions of OS X can read NTFS file systems, they just can't write to them.

2. You could use the fake symlinks that OS X is creating. This would require writing a parser to interpret the links or finding a library that does this for you. I don't have a copy, but I believe the XSym format is covered in the "OS X Internals" book.

3. You could rethink the approach to your problem so that it doesn't require you to use symlinks.

If this didn't solve your problem, then please provide more details because I had to make some guesses about your situation.

==EDIT==

Take a look at the subversion documentation on symbolic links here. The relevant quote from the doc is:

Versioning Symbolic Links

On non-Windows platforms, Subversion is able to version files of the special type symbolic link (or “symlink”). A symlink is a file that acts as a sort of transparent reference to some other object in the filesystem, allowing programs to read and write to those objects indirectly by way of performing operations on the symlink itself.

When a symlink is committed into a Subversion repository, Subversion remembers that the file was in fact a symlink, as well as the object to which the symlink “points.” When that symlink is checked out to another working copy on a non-Windows system, Subversion reconstructs a real filesystem-level symbolic link from the versioned symlink. But that doesn't in any way limit the usability of working copies on systems such as Windows that do not support symlinks. On such systems, Subversion simply creates a regular text file whose contents are the path to which to the original symlink pointed. While that file can't be used as a symlink on a Windows system, it also won't prevent Windows users from performing their other Subversion-related activities.

Basically, it says something similar to what I mentioned earlier, which is that symlinks are not supported that well if at all on Windows systems. Subversion just creates text files with the contents of the link so you can choose to either figure out how to parse these text files yourself or try to find a library that will parse them for you.