I'm thinking about this problem, I know the way I'd like to proceed, but I do not know yet how to implement it (and when I say "how" I mean that theoretically I don't know if I should use TFTP, FTP or other methods, not that I need the code..otherwise there will be no fun for me!! ahah).
I would like to write an application (c, c++ or c#) that is able to connect from a Windows PC to a Linux board to modify files.
What I actually do (manually) is:
serial connection to the board;
open the Linux console;
login as root;
change directories until I find the configuration file that I want to change;
open the file with VI and edit it;
reboot from Linux console.
Do you think there is a way to do this automatically? I mean, login as root, copy the target file on the pc, and then upload to the board the modified file? I'm asking this, because I don't want to take the risk of accidentally change something wrong.
Thanks all,
electroDi
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.
We design a USB MSD product, for that we need to write a C# application which will do some processing on the files stored in the memory.
Can anybody advise me,how to detect whether an USB device with a
particular VID+PID is connected to the computer and if so, what is
the drive letter(Or root drive path)?
I could able to find examples to detect whether a particular(VID+PID) USB device is present or not.
And also could able to find example programs to detect the available removable drives and what is the path...etc.
Is there any example programs in C# combining these together?
Thanks for the support.
I was going suggest using a wrapper around the SetupApi but it looks like someone else has already put together a really good answer. DEVCON.EXE (driver tool) and OpenVPN
The title sounds a little confusing so let me clarify.
I want to be able to stop (for example a .exe file) from being imported onto the machine the USB drive is plugged into.
Is there a way to stop a list of file extensions coming from a USB drive?
What I am shooting for...
My application will be running and whenever one puts a USB drive in and drags a .exe file to the desktop, I want my application to check its extension type and delete the file or block it from even coming onto the computer.
Is this even possible? If so, how? Maybe this can be done better with a different language?
Mainly, I would like to block .exe, .msi, .zip, and a few others.
You should be able to get by with the FileSystemWatcher since you're only watching the desktop and subfolders.
I have a legacy program that reads/rips CD/Music data from a disk. It is a custom program that reads the track data and converts it to wma/wpa/wav format. The user then enters how it is to be licensed and the program ingests the data and music files to our LAN.
The issue is the program only works with a handful of CD-ROM drives. I was wondering if there was a program or some way to make the program point to a generic drive via driver or virtual drive and actually have it read a more advanced CD/DVD drive?
Here is a rough diagram.
[generic cd-rom virtual drive] ->[mapped to]-> [any number, make, or modal or cd/dvd drive]
This way my program will always see the same generic CD-ROM drive and I can install it on any PC with any type of CD/DVD drive.
Is this possible without having to perform a re-write on the program? I am really looking for a quick fix.
The program is written in C# Visual Studio 2008.
After much testing I ended up using XP Mode for Windows 7. This gave me a quick generic CD-ROM bolted to any CD/DVD drive. I know this is not technically a programming fix but it is a fix, in some way, to my issue. It will at least buy me some time until I can get and actual code fix in place. I will post the final fix if/when I find one.