I was wondering if there was a way to make a *.dll that mounts archives in Windows without the need for installing drivers. I've tried mounting *.isos (and was successful), but I needed to install drivers, which was not something my intended audience wants to do (or can do). The other relevant alternatives were for Linux (fuse-zip) or dead projects (zipios++).
Something along the lines of this...http://mountziplibrary.codeplex.com/
Oh, and it'd be great if the solution was GPL v3'd or at least open source.
Thanks.
Have you looked at Dokan? It looks like a Windows equivalent to Fuse.
What you're describing is called an Installable File System (IFS). It theory you don't need a driver: implement a SMB server in application space, and let the existing kernel network client talk to that. It's just TCP/IP at that level.
The proper solution is indeed an IFS driver. Fundamentally, drives are objects in the kernel namespace. As such, the code for them should be part of the kernel, and an application never is.
There was a hobbyist project called WinFUSE once, which worked as an SMB server and redirected FS requests to your .NET code. But it's gone, as far as I know. Proper way is to use a driver-based approach. The driver can be installed and removed on-the-fly if the user has admin rights, and if he doesn't, installation of the application requires admin rights anyway. In Unix/Linux it's the same - you can't mount a disk (not saying about the driver now) if you are not an admin. Could I not mention that Callback File System is the only professional supported solution that lets you accomplish the task?
I've decided to Google around for some answers.
One of particular interest was zziplib. It's for C and transparently accesses archives, just like Windows does, treating it as an actual folder.
Of course, the other implementations given by users work too. This one just fit the bill for me.
Maybe this one helps you: ZLib
Related
I was asked recently to install Hubstaff (a famous application for tracking your data, like screenshots, URLs, etc., on your computer and reporting it to your management team) on my Debian machine. After checking their download page (https://app.hubstaff.com/download) I found out that for the Linux version, I have to download a .sh file and run it (so no package manager, not a .deb file) This app tracks almost everything from my machine (https://hubstaff.com/how-tracking-works), but they don't explain how it follows them. Like they can track the URLs I visit (and no matter what browser I use), how do they do that? Are they checking my network packets?
Do you guys think is it safe to do such a thing? E.g., they say they don't track my keyboard, but they can find out if it's used or not (for idle purposes). Well, they might be right about it, but what if somebody hacks them? I feel like if I use this app, I am making my computer public. Please help me learn about it.
I'm a web developer that needs to build a piece of software for my local office of about 20-30 Windows computers. It needs to automatically and silently run software updates and deployments on all computers.
The Windows computers run on a local network. I'm not sure where to start putting my hands on with something like this... I'm an experienced programmer, just need the right direction on what to read.
I know each Windows client has a Samba server, and also we're using Active Directory, but I'm not sure how that works.
How would I go about starting developing this? I'm sure there's Windows APIs for samba file transfers, but I also need to know about documentation on silently installing the .exe or whatever, and also I need APIs to know the applications running on the client to understand if they need to be updated.
Where's all these APIs?
Have a look at wpkg.org. It's license is GPL. It runs on Samba in an Active Directory. See also their feature overview.
I mentioned Samba only because you also did so. Though your exact words read: 'I know each Windows client has a Samba server [....] though I'm not sure how that works.'
In case you meant that each Windows client has access to a Samba server, my answer may be contributing to help you.
In case you thought your Windows clients are running Samba themselves, this is impossible (but my answer may help to clarify a few things nevertheless).
Here's why:
Samba is an implementation of the Microsoft SMB stack of networking protocols for Unix-oid operating systems.
SMB is what all Windows computers use natively.
why exactly you want do develop this application
there is a Microsoft product responsible for this thing . it is called SUS server
We have an app that currently installs itself into 'program files\our app', and it puts the internal data files into the common Application Data folder. This means the program is available to any user on that particular PC.
Now we want to make a multi-user version of this program, multiple PCs accessing the program at the same time across the network.
In the bad old days, under XP, we'd just have the user who installed the app 'share' the app directory and off we'd go. In principle, is this still the 'right' way to do it under Vista/Windows 7?
We'd like to do this 'properly' and be as compliant as possible! Is there a recommended 'Microsoft' approach for doing this, or is it largely down to whatever we can get away with and subsequently support (hah!). I've tried researching this on the MS websites but not found anything too helpful at all - it'd be really useful to have a 'if you're trying to install this kind of thing, put it here' type guide for developers!
I think the recommended way to deal with this is one of the following:
Package the application as an MSI and distribute it via group policies to all machines on the domain. Yes, this will install it on every machine but that's usually how it should be done.
Install the application once on a server with terminal services and push a shortcut for running the program on that server to every client machine. You can transparently use single applications on a terminal server. Afaik you can even associate file types with those on the client machines.
Reading between the lines from other resources, and trying to make sense of it all, I've decided that the 'right' place to put the program data for this stuff really will be in the AppData (Roaming) folder, and the right place to put the program binary files themselves really will be the Program Files folder of the host computer, which I can then share out.
I'm working on a windows platform and want to be able to auto sync my files one way 'on change' to my virtual windows or linux web server - also need to be able to filter file types. i can connect to the remote machine via network drives.
i'm ideally looking for a free, easy to set up solution - a commercial product that does what I need is called ViceVersa but its a little overkill and costs :)
Thanks
Josh
I'd use rsync - simple, easy to setup, and provides the filters you need. Also very low on bandwidth after the first pass.
Here is a link explaining how to get it working in Windows
Whilst rsync doesn't allow 'on-change' auto-syncing, it is very fast when it scans a sync'ed directory (even very large ones), so you could schedule a frequent sync to overcome this.
Edit: You could combine it with a program like this, to trigger an rsync on folder contents change. Cheaper than viceversa
For other users, its worth mentioning lsyncd, it will auto sync on changes between two machines (by default deferring to rsync). Will only work on Linux though, but if thats not a problem it works great.
It also seems that Sparkleshare has finally released some working code (Dropbox clone). Havent tried it myself but does cross-platform synching and you can setup your own server.
I was reading the post Installation file names in Windows Vista when I thought about Installation File Names. I'm a addicted software downloader, and frequently I've got installation names like "setup.exe" or "install.exe", that says nothing about the program to be installed.
I think that an installation file must be like:
Install[ProgramName][ProgramVersion][Platform].[exe|msi|etc]
or
[ProgramName][ProgramVersion][Platform].Setup.[exe|msi|etc]
What your thoughts?
I much prefer descriptive install file names. Sometimes, you want an emergency 'restore' disk to get a machine up and running even without internet connectivity. When all your installs are named "setup.exe", you either have to rename them all, or create a directory with a descriptive name for each one.
An example of where such a disk would have been really handy was when I took my brand new laptop in to work to use while I upgraded my desktop to Vista 64, and then Windows 7. I only have one wired LAN point, so my laptop needed a wireless connection for internet access, to download my installs. I had to download them all on my desktop, and then transfer by flash drive to my laptop. Very inconvenient.
Not sure this is entirely programming-related... but installer files are usually meant to be transient. You download them, run them, and delete them. (Or at least, I think most people do) So it doesn't matter much what the filename is.
I don't think there's any reason not to give the installer a descriptive name... but I certainly wouldn't say it "must" have one.
For CD-Rom based installation, I'd suggest sticking with SETUP.EXE which helps with autorun detecting software to install from the disk.
For downloadable files, just add the appropriate manifest to the EXE and Vista won't have a problem with it. I'd suggest something semi-descriptive, but there's no need to go into great detail unless it's something like hardware drivers that a person may archive off for reuse, otherwise the file name is confusing to non-technical people.