I have seen many sync clients such as Dropbox that can create "virtual" files that do not really exist on disk. They have a size and you can open them in any program, but they are streamed e.g. from the Dropbox servers.
I don't know how this is called, and I can't find any information about this on the internet. Do I have to write a file system driver for that, or is it possible to do this for example with the Windows API?
Dropbox is a file hosting service. (From WiKi)
On Windows you can use OneDrive to store files on Cloud.
Please refer to "Create file to Onedrive programmatically from C#?" for an sample.
Similar topic: "How to create a virtual file?"
Related
is there a possibility to change the Dropbox sync folder (aka "Dropbox location") programmatically on Mac OSX? By programmatically I mean by executing some command line helper tool or by using the Dropbox API.
I've searched around for this quite a long while now, but couldn't find any satisfying answers.
Sym-linking or using an alternative cloud provider (with a possibly better CLI/API) as suggested here are not an option for me.
As I understand the Dropbox API, it is made for accessing the Dropbox Server storage from within one's own application rather than interacting with the "out-of-the-box" Desktop sync client, is this correct?
The solution I am looking for should also work very reliably, so "hacking" the encrypted SQLite dbx files (as suggested here) or an Apple UI script that changes the sync folder via the Dropbox UI Desktop client are also really not an option for me.
For Google Drive I know that doing this is a simple as stopping the sync client, moving the sync folder, changing the sync path in the sync_config.db accordingly and re-starting the Desktop sync app. -- Exactly such a procedure is what I would also be hoping to find for Dropbox :-)
THX for your replies & suggestions!
No, without using the potentially brittle methods you mentioned, I don't believe there's a way to do this programmatically.
Your understanding of the Dropbox API is correct though. Using the API allows you to communicate with the Dropbox servers directly to interact with the account, and not the local desktop client.
"User1" sits in front of a client PC of a small LAN and process an .xlsx file, which is located in a shared network folder . "User2" tries to access the same file (or a shortcut of it) and gets "this is a file in read only mode", and can't modify it's content.
Is there a setting allowing concurrent use/modification to happen? For example by using instances of the file or something...
Thanks in advance!
p.s. Both users have xp and excel 2003 installed. The DNS server which hosts the file has a win server 2012.
It looks like Excel has a built in "Share Workbook" feature that may help you with that problem.
This link here http://www.techonthenet.com/excel/questions/shared.php provides a good description of how to use it.
I am able to write to a .txt file in Windows Phone 7. I know I can read this file programmatically, but how will I be able to get this file to a PC? Where exactly is the file stored on the phone?
The SDK comes with the Isolated Storage Explorer tool which allows you to read and write files from Isolated Storage. Learn about it's usage at http://msdn.microsoft.com/en-us/library/hh286408(v=vs.92).aspx
This assumes that you're wanting to do this with files you're creating for dev/testing purposes.
If you want to make an application which allows you to create files which users can access from teh PC you're out of luck. Instead you'd need to look at emailing the info from the file or distributing the file via the web.
We are developing a web based application which provides a repository of users case files. Would like the user to be able to access these from their web browser with full read write capability.
For an earlier generation of our system, which was hosted on a local Linux server with Windows clients we were able to share out a folder and access it with \\server\share_name\file.doc type links. If these type of links were included in web pages (in internet explorer) and clicked on the file opened in MS Word and was savable directly into the shared folder. These type of links however only worked in IE - not FF or Chrome
Moving now to an internet based solution in our next generation of the system, we require similar functionality.
We are toying with the idea of having a WebDAV (or FTP/SFTP) share and mapping a local drive on each client machine to it to provide similar functionality. This though will probably not work well with FF or Chrome with \\server\share_name... type links. We have done brief testing and file:// links do not provide write capability once the file is opened.
As a last resort we will be able to use manual file upload dialogs, but this is not ideal and would entail additional end user training.
Has anyone any similar experience in this field and any possible solutions / best practice.
When you map remote resource as a local drive, for a browser this becomes a local drive. And browsers have only limited access to the local file system. Now when you provide a link to the browser, the browser's default behavior is to download the resource behind the link, and then let the local application process it. The browser just doesn't know how to open the remote resource locally in a different manner.
The solution would be to let the browser download something (some kind of link file) and have some local helper module (external application or browser plugin) open this link file and open the location, specified in this link file, locally. As this would be a client-side helper module, it will be able to interact with the client system and will know how to open the provided link. Given that the virtual drive letter can be different on each system (if you mount the disk to the drive letter), the helper module would need to resolve the link to point to the correct local drive. If you create a hidden virtual drive (our virtual storage products let you do this), then a link would look like "\SomeFancyNameUniqueToYourApp\Path\To\File.ext" and no resolving would be necessary. And most applications handle this type of paths fine.
I don't know for sure, but it's possible that browsers will open Windows .lnk files without a need in helper module, and with hidden virtual drive you could generate an LNK file on the server and have the browser open it locally. But this is just a guess. My bet is that you will need a helper module anyway.
ftp://username:password#hostname/ type links should work, and MS apps are getting better at handling them. still not 100% though
Try SMEStorage.com. They enable you to map local WebDav and FTP servers and access files using a Cloud Drive on Linux, Mac or Windows, and also from mobile devices (iOS, Android, BlackBerry and Windows Phone 7). You can get unique file links for each file and also secure file sharing in which the links expire.
There does not appear to be any good software to mount an FTP to a local drive letter (see here for details SF Question) so I was thinking why not just write it myself, but I have very little experience dealing with windows (at the programming level) so what would be involved in doing something like this? What needs to be done to get a new "drive" listed under "My Computer"? What needs to be done to then get the contents of the FTP (or other remote resource) listed that "drive"?
My initial thought would be you would need to write a shell extension to be able to show your FTP site, and that it would best be shown as a special folder in Windows Explorer. Your extension would ideally be written in a non-managed language that supported COM (C++, VB 6, etc). It would need to respond to events like:
The user highlighting a folder on the server
The user double-clicking on a folder on the server
The user dragging and dropping files to and from the server
The user wanting to disconnect/reconnect from the server
When you intercept these events you would issue the appropriate FTP command to accomplish the task (use LIST to get the contents of a directory, MKD to create a directory, STOR to upload a file, etc). You would have to take the results of these commands and show them in the folders view and the listview within Windows Explorer, and for that you will likely need to get up close and personal with the Win32 API. For that you can turn to books like Charles Petzold's classic Programming Windows. Also check out this tutorial on writing shell extensions.
It sounds like an interesting project.