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.
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:
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.
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.
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.
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
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:
an external repo (schema://server/path)
relative to the same repo (^/path)
relative to the schema (//server/path) or
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.
Related
I would like to know how Windows generate folder, where will be ClickOnce application installed.
In Startmenu is "shortcut" to file, what is putted in some "startrek" folder like:
C:\Users\USERNAME\AppData\Local\Apps\2.0\GT??4KXX.PRJ\EGV???1G.??C\prin..tion_7???5a2?????74b6_0000.0002_1dae????89111c35
What does those folder names mean?
For example:
If i will have for example some settings.txt file where i want that user can change some parameters of the application. Is there way how to know, WHERE it will be installed and WHERE the file is? (Where user will find this settings.txt file).
I know that i can create the file for example in C:\ and after start the application i will modify the file in "strong" path. But i dont really like too much files, folders, whatever in C:\ and i prefer to have settings files in same folder like the application. But with ClickOnce installations is it really hard - impossible - to find that file.
It seems like when the "startrek" is something like hash of the project.
So i would like to know what does the folder means and if its some hash of the project or what is that.
To find the folder that contains your executable, you can use the Assembly.Location property.
For example:
string exeFolder = System.Reflection.Assembly.GetExecutingAssembly().Location;
However, if you want to store settings for your ClickOnce app, you shouldn't do it by writing a file to the .exe's folder.
Instead, you should use Microsoft's Application Settings support. Doing it any other way is going to be a lot of extra hassle, and Microsoft's support is very good. It does need half an hour to read through the documentation, but it's far and away the best thing to do, IMHO.
(I'm assuming that you only need the settings to be stored on the local PC for the same user to use later. If you want the settings to follow the user around (i.e. roaming settings), you can't use the Microsoft support.)
If you have more complex settings that you want to store in a file that you create directly, you should consider using the isolated storage that the answer from JRoughan mentions.
From inside the ClickOnce app you can find the default directory where files are stored using
ApplicationDeployment.CurrentDeployment.DataDirectory
Or you can use isolated storage and choose whether you want to save per application or per user.
I don't think it's possible to determine these folders from outside the app itself. If you need a known location you'll have to hard-code it.
Update
I also don't believe it's possible to infer what the install directory will be for an app. It would be unwise to use even if possible as updates to the app will not be in the same location.
If you have data that the user is modifying through your program, you will be happier if you don't leave it in the ClickOnce program directory. You can get completely messed up when there's an update. Check out this article about what to do with your data to keep it safe and be able to find it. It talks about putting it in LocalApplicationData, but if you want your user to be able to find it and edit it, just put it in MyDocuments/yourappname/settings or something like that.
I wouldn't use Isolated Storage; there are reported problems with that and ClickOnce.
Just as the title states, is there an Adobe equivalent to the Java deployment.properties file?
I am writing a c# application to test installations of application in our network. The top three on my boss's list are java, flash, and reader. I need to be able to find out what versions of each application are installed on a machine for the reports im going to generate (force the user to update/etc).
I know i can check version number and confirm the ability of IE to access my JRE by checking "\Sun\Java\Deployment\deployment.properties". What file would I check to confirm the same for adobe reader and flash?
Thanks in advance for any help given or links provided to more info.
edit: I need to do this from the browser.
This is not a very clean solution, but since the only "official" way seems to be to check it from the Windows registries perhaps this will help:
We know that the flash files are located are in the (windows directory)\system32\Macromed\Flash (or SysWow64\Macromed\Flash on 64 bit systems).
Each time a flash updates it keeps the track of the progress in the log files. Depending on the flash version you will either have a) install.log (very old versions of flash) or b) FlashInstall.log
a) If you browse through the file you see various entires and one type goes like this:WriteRegStr: "HKEY_CURRENT_USER\SOFTWARE\Macromedia\FlashPlayer" "FlashPlayerVersion"="10.0.45.2".
Now you can just go through that file bottom-top and match the "FlashPlayerVersion"= string to get the most recent version.
However, this is for a really old versions of flash and the install.log file never got deleted from this directory, so make sure you check for the FlashInstall.log too!
b) Use a similar approach, except the new install logs don't keep the "WriteRegStr" information. Now you can instead look for the dll file name itself, for example my last update created an install log 0009 [I] 00000014 C:\WINDOWS\system32\Macromed\Flash\NPSWF32_11_5_502_146.dll, meaning my flash version is 11.5.502.146
another options are to
check the plugin core files creation date and compare with the versions release dates (quite unreliable in case someone somehow manages to install an older version)
check the actual property of the NPSWF[..version..].dll file. You can see all the complete and precise version details in the "Version" tab. however, I don't know how to access the rightclick->properties from inside a script, so you'll have to find out by yourself if you decide to go for this option
ask the unicorns
I recently got put on a project where they're having issues with too many files in a folder slowing down access. I believe it is 10,000+ files in a single folder where windows starts to slow down access, we have something on the order of 50,000. All the files are small and most of the time we only need to access the newest .1-2.% of them via windows file and print sharing. I'd look into dividing the files into subfolders, except that there is a bunch of legacy code that is only able to look at a single folder.
My idea - I don't know if it is possible or even plausible - is to create a small program that buffers the newest .1-.2% files in memory, and retrieves the rest from disk as needed.
I had thought that years ago I'd read of a protocol that could simulate a folder on a hard drive. Is it possible?
Is there something out there that already does this? Is there a better option without major changes to the system?
What to other systems use for serving up a large number of files? Is there some other product that serves files that we could map as a network drive? Or some way to blend 2 folders so they look like one?
Putting aside the "correct way to solve this problem" for the moment, what you're looking for is called "Shell namespace extensions". There are several .NET resources for writing these explorer extensions.
http://namespaceextension.codeplex.com/
http://www.codeproject.com/Articles/1649/The-Complete-Idiot-s-Guide-to-Writing-Namespace-Ex
http://www.codeproject.com/Articles/13515/A-Namespace-Extension-Toolkit
And perhaps many more.
Of course - we must remember why it isn't a good idea to write explorer extensions in .NET.
Hope this helps.
I'm getting the same kind of error as described here. I'm running in to the file name limit of windows in TFS Build. The answers to this question suggest redefining the build agent working directory. I'm not sure if I should do this. I have a few questions...
Does changing the build agent working directory affect me, or everyone using the build agent?
The build agent is not ran by me, it's on a different computer controlled by a different department in our company. I can get to the "manage build controller" settings, and I seem to be able to make this changes, I'm just scared to!
There are a couple of options here, changing the build directory on the build agent, in Team Explorer right click on the "builds" folder and select manage build agents. Select your build server(s) and change the build folder to something like "e:\b" (or even "e:\" if that's all you use that drive for) This will change the build working directory for that build server. This will shave a few characters off the working directory.
In addition to this you can map the workspace used by the build as far down the tree as possible. This is a good idea to do even if you're not running out of characters on the path as TFS uses the workspace to determine which code to get for your build.
e.g. If your workspace is mapped to $/TeamProject = $(SourceDir) this means TFS will get all of the code in the team project for the build. Even if you only want 1 solution from 1 branch
Consider a Team Project set up like this
`$/TeamProject/DevBranch/Docs
/Source/Solutions/Solution1
/Solution2
/etc...
/More Stuff
/MainBranch/[Same As Dev]
/HotFixBranch/[Same As Dev]
/ReleaseBranch/[Same As Dev]`
If your workspace is mapped to $/TeamProject you're going to be getting everything from TFS when all you really want is the code in the "solution2" folder from the dev branch. Change the mapping to $/TeamProject/Devbranch/Source/Solutions/Solution2 and you've just shaved about 60 characters of the length of the path. In addition to this you'll speed up the builds as it will only get the code they need.
It is used by every build task that uses that build agent so yes, it could affect multiple people. If you're running into a path limitation, you should definitely change the working directory. I would just clear it with the other people in the department before you proceed, just to make sure everybody knows what's going to be done.
The full qualified name must not exceed MAX_PATH which is on Windows 260 characters. In reality there different values used for various tools.
The GAC e.g. does reject file names which exceed 256 characters. With file name the path and the file name itself is meant.
TFS is built upon Windows hence the same limitations exist for TFS builds. The only feasible solution is to use a workspace directory which is as short as possible to limit the amount of issues you will run into. You could try to subst the workspace directory to make it even shorter but the fundamental file system limitation will not go away.
Yes Microsoft should solve this issue but in reality it is not feasible soon. Any tool (MS and non MS) which is used during the build will run into the same limitations. At best the tools will crash when the file names get too long. In the worst case you get corrupt binaries without noticing. All applications which are written in C/C++ use for file name buffers a MAX_PATH+1 sized buffer. Even if Windows would allow such file names (there are ways but ...) the buffers of nearly all applications would be too small to make use of them.
You are not alone we all suffer. On the bright side this limitation does prevent nitpick architects to enforce naming conventions which exceed MAX_PATH alone with the target name.
So I have been writing to
Environment.SpecialFolder.ApplicationData
this data file, that upon uninstall needs to be deleted. I am using Innos Setup to build my installer. It works great for me. So my data file hangs out in the above path and I do that cause when I used to try to write it to
Application.ExecutablePath
certain boxes I tested it on would throw a nasty error at me trying to write data there. I do research and somehow its not always writable and its how i came up with the Environment.SpecialFolder.ApplicationData
That is why my data file now resides in the SpecialFolder.ApplicationData. Trouble is if the user uninstalls and reinstalls I need that file gone. It might be a short coming of my knowledge of Innos but I cannot figure out how to know where that file will be to tell innos that.
So then I thought I had a clever solution: Innos can run a file when its done uninstalling, so I had my program create this file "uninstallData.bat" that says:
del "the file in my special folder application data path"
and I wrote it out to drumroll
Application.ExecutablePath
(yes it was a while in development and I had forgot it was't doable.)
So of course I am back to square one, I need to write a file to a path Innos knows about {app} and I need it to be able to delete my data file in the SpecialFolder... i don't care how I do it i just need that file gone.
Are there other Environment. or Application. approches I have missed? Maybe somewhere that is viewable by an uninstaller AND can be written to?
As an aside, I am not sure why my box I develop on can write to the application folder no issue, but it cannot on other boxes... weird.
Any input would be great sorta lost as to how to crack this nut.
The environment location is in the user profile. If there are multiple users on the machine, and they all run the application then a copy of the file will be in each profile.
The path also depends on the OS.
Regardless, the current user's app data location is pointed to by %APPDATA% and %LOCALAPPDATA%. These Windows environment variables should be available within Innos.
Appliccation.ExecutablePath is not writable per standard defintions - the program files folder should never be manipulated by running applications. Ther area number of special folders for that. Nice that you finally found.... what is properly documented by Microsoft for a LONG time now (minimum 10 years).
I suggest you get a proper installer - WIX comes to my mind. Your problem is totally unrelated to C# - it seems to be totally a "crappy installer" issue. Or provide a PROGRAM (not bat file) to run at uninstall. What exatly is your problem there?