Trick windows into thinking network drive is local

Status
Not open for further replies.

Karmashock

Posts: 223   +0
I use a few programs that for whatever reason will not talk to mapped networked drives but will talk to local drives.

This is extremely annoying because at least one of them is a backup utility.


What I'd like to do is trick windows into thinking a networked drive is local.


Any means you know of to get \\computername\sharename to be treated as a local harddrive would be appreciated.


Why any program would refuse to talk to networked drives is beyond me. The whole point of mapping drive letters was to get dos programs to talk to remote drives. So why would some windows programs have an explicit inability to talk these drives?... the only thing I can think of is brain damage.
 
Are, the joys of Dos ! You used to be able to map a networked drive with a MAP command and can still do the same thing in Windows Explorer. It is under Tools - map networked drive.
 
Are, the joys of Dos ! You used to be able to map a networked drive with a MAP command and can still do the same thing in Windows Explorer. It is under Tools - map networked drive.
I know.

However, windows still regards it as a networked drive.

DOS as we both know does not recognize the distinction once it's been mapped but windows does.

In fact, windows also recognizes the difference between "Fixed" and "removable" disks.

Ideally, what I'm looking for here is a way to make the computer view \\computername\sharename as a fixed disk with a drive letter.


I've heard that the only way to do this is with registry edits... if that's the only way, then that's fine. However, if there's a program that will do this that's even better as it's bound to be more flexible... and I'll be less likely to do something horrible to the registry.
 
1) I'm only taking a guess here... As to why... Even tho it might look like just a drive letter to you, at the lower levels there's alot more issues to deal with for a network drive vs local (e.g network speeds very different, less predictable then internal bus, you have to logon and have permission to network drives, etc.)

2) But that said, i think many apps came out initially with no network drive support but followed and support them.

3) So am also curious what platform are you running on, what programs/versions do you have the trouble with?

4) again, only, a guess but don't think u could "trick" windows.. and even if you could, you would have very undependable data transfers as windows wouldn't do all it needs for network drive support
 
1) I'm only taking a guess here... As to why... Even tho it might look like just a drive letter to you, at the lower levels there's alot more issues to deal with for a network drive vs local (e.g network speeds very different, less predictable then internal bus, you have to logon and have permission to network drives, etc.)
Technically... maybe. It depends. In this situation the only effect should be reduced performance which isn't a problem.
3) So am also curious what platform are you running on, what programs/versions do you have the trouble with?
Windows XP mostly... as to the programs there are a several. Some backup programs and automation utilities.


It's an annoying problem.

4) again, only, a guess but don't think u could "trick" windows.. and even if you could, you would have very undependable data transfers as windows wouldn't do all it needs for network drive support
you can... there are some registry edits that will do it.

As to the unreliability, it's a risk I'm willing to take... and I'm prepared to play with the settings until it stabilizes.
 
Technically... maybe. It depends. In this situation the only effect should be reduced performance which isn't a problem.

Windows XP mostly... as to the programs there are a several. Some backup programs and automation utilities.


It's an annoying problem.


you can... there are some registry edits that will do it.

As to the unreliability, it's a risk I'm willing to take... and I'm prepared to play with the settings until it stabilizes.

OK.. but why would you want an undependable data transfer? especially when you're doing backups? and when there are backup programs out there without that risk to your data? (am curious. not arguing... just wondering why)
 
OK.. but why would you want an undependable data transfer? especially when you're doing backups? and when there are backup programs out there without that risk to your data? (am curious. not arguing... just wondering why)
the unreliability would be the exception to the rule.

It would be like telling the computer that a removable drive is a fixed drive or a fixed drive is a removable drive... it's not as important as you think it is...

I would be very surprised if it were in anyway unreliable and even if it were there would be ways to fix it.


My primary concern here is a simple way to get windows to label a mapped networked drive a fixed drive.
 
Dos is/was brain dead in ignoring the issue in the first place. As there are always
better programs available today, you should reconsider using anything that is DOS
related.

Sometimes, people will say DOS xxx when they are using VBS or other scripting tool,
but those tools are blind as to the condition and would be happy with a mapped drive,
so this is not a suspect.

Understand the I/O being performed and the possibilities of 'not completing as intended'.
  • HD I/O runs directly to the device controller and device; when the driver returns the I/O is completed or retried.
  • A mapped drive runs NETWORK actions to the Nic to another Nic, to a software chunk on another
    system and Finally down to the controller and the device.
Network I/O is far more complex and has several issues that HD I/O never has to consider, eg;
  1. concurrency from progams on the other system
  2. the inability to LOCK access to the HD to ensure that the same record is not being written by some other program
  3. and don't forget the other system can BSOD or the network can fail
The Samba (file sharing) software has all these things under control, while native
HD I/O does not.

I recently saw Quickbooks get upset when accessing a mapped drive for these reasons.

The condition is also seen when someone attempts to install a non-networked program on a
server and then attempts to have multiple user run it at the same time. Good way to scramble your database.
 
Dos is/was brain dead in ignoring the issue in the first place. As there are always
better programs available today, you should reconsider using anything that is DOS
related.

Sometimes, people will say DOS xxx when they are using VBS or other scripting tool,
but those tools are blind as to the condition and would be happy with a mapped drive,
so this is not a suspect.
Well, I do use some "new" dos programs in that you can only interface with them via the command prompt. But they're not the problem. I generally prefer command prompt programs for server tasks because they're much easier to automate. The GUI is great for when you're doing something yourself, but it's a serious pain when you're telling the computer to do it automatically... I use programs like Autoit when I don't have a choice... but that's never as reliable as the good ol' command prompt. Linux and Windows could stand to learn something from each other. Linux could use better driver support and general ease of use like windows... and windows could really use a more sophisticated command prompt environment.

/rant

The problem is a few Windows(GUI) utilities will not even TRY to read a networked resource. What I think I need here is something that will create a special "mount" of a networked resource and host it on the local system "as" a local resource.

Ideally, the mounting program would handle any protocol difficulties between fixed and networked drives.

I recently saw Quickbooks get upset when accessing a mapped drive for these reasons.
Yeah, I've seen that sort of thing before... but it's always manageable. There are ways to make it not happen.

The condition is also seen when someone attempts to install a non-networked program on a
server and then attempts to have multiple user run it at the same time. Good way to scramble your database.
Yet another reason why I hate programs that aren't self contained.


Think about it... you can take some piece of crap software from 1990, throw it on the server, and EVERYONE can pretty much use it at once without a problem... try that in 2008 and you get doom.

I feel that in a lot of ways we have less flexibility in how we use things now. Too much dependency on the registry... code is too messy... the whole architecture is in need of an overhaul. Ideally one that doesn't make it incompatible with the legacy.
 
I understand the GUI vs Automation conflict -- bugs me too at times. However,
the world has left command line programs in the grave yard, unless you
like Linux/Unix shell programming, eg
rcp ./*.doc remoteHost:~myid/archive/​
which copies local .doc files to another system.

At the same time, I like Alway Sync which has a GUI for the configuration and scheduling,
but performs a two-way sync of folder-pairs on different systems.

"Mount" is tightly integrated into the OS, and you're not going see some package
begin offered at any price with the description given.

Actions between systems is the realm of Client/Server software and you just don't
get that in "DOS".

Like I said originally, DOS was brain dead in ignoring the issue of networked files and
that lead to many cross-linked files -- oh yea -- let's all go back to DOS (teasingly).

You're between a rock and a hard spot on this one and gently suggest you save time and effort and look for other 'available' solutions.

wishing you the very best ...
 
I understand the GUI vs Automation conflict -- bugs me too at times. However,
the world has left command line programs in the grave yard, unless you
like Linux/Unix shell programming, eg
rcp ./*.doc remoteHost:~myid/archive/​
which copies local .doc files to another system.
I'm not sure about that... batch scripts are very common and many common GUI apps accept command line triggers and switches.

It's not even really dos anymore as most of these programs only work within CMD and wouldn't run in a pure dos environment. It's just command line interaction.

And the fact that this mode is thriving on linux is indicative of it's general utility... therefore I don't see it dying on any future OS (Windows, linux, OSX).

Beyond that, a real virtue of command line interaction is not only automation but getting different programs to talk to each other. Once a given program starts not only accepting input via command line but outputting something as well... it becomes very easy to integrate various programs into a unified system. Trying to make that happen in GUI is difficult, unreliable, relatively slow, and tends to make multi tasking difficult as such things tend to monopolize the UI (as opposed to a single command window that you can minimize and not worry about screwing up other things).

That valuable... This is one of the major reasons I try to use programs that at least accept command line interaction. For example, I use a credit card gateway program that has a GUI and is typically interacted with the mouse. However, going through the process of importing billing information into it every day manually, and then executing the billing operation is a pain in the ***. So instead I have a batch script that tells my windows database to output a comma separated text file with the relevant information, wait for that to be done, execute the billing gateway, import the info into the billing queue, charge it, delete the comma separated file, terminate the credit card gateway upon completion, and then create a system beep to let me know it's done.

The whole process takes something like 20 seconds and only ties up the database program and credit gateway. No crazy windows popping up... no mouse cursor jumping all over the place, no having to worry about touching the keyboard while it runs. THAT is multitasking.

Now sure, I could gave gotten a database or credit gateway that would seamlessly integrate with each other. But no such system exists that works as well as this system does (excluding some proprietary custom programmed system that I cannot buy and could not afford to have programmed). I would have to accept an inferior database, inferior credit software, or an inferior bank (rates) to make that happen.

So I said screw that... and wrote a two page batch file that handles the integration, works 100 percent of the time, and seriously makes blue birds appear out of no where and sing on my shoulders.

it makes the world a better place...

"Mount" is tightly integrated into the OS, and you're not going see some package
begin offered at any price with the description given.

Actions between systems is the realm of Client/Server software and you just don't
get that in "DOS".
Then why can I mount files as CDROM disks (Daemon Tools)... or FTP sites as networked drives (Net Drive)?

All it has to do is emulate a fixed device driver and then handle the protocol shift between the network share and the mount point.

Ok, that's not easy but there are lots of programs out there that do more complicated protocol shifts.
Like I said originally, DOS was brain dead in ignoring the issue of networked files and
that lead to many cross-linked files -- oh yea -- let's all go back to DOS (teasingly).
I like programs that don't assume they're smarter then I am... Yes, DOS is stupid but I'm not and I'm willing to do the thinking for it. Windows is simply denying me the option to even try.

I find that annoying. Doubtless the first attempt will lead to pain and tears. But the second might work...
You're between a rock and a hard spot on this one and gently suggest you save time and effort and look for other 'available' solutions.
I think you're right. It will probably save time to try to bypass the whole issue by using a program that is specifically compatible.

however, i might just use a program that is too stupid to know the difference... and avoid problems by doing the thinking for the program... instead of assuming it knows what it's doing.
 
I think you will recognize my Avatar ... clearly I understand the command line paradigm.
It just doesn't fit well with Windows :)
 
I think you will recognize my Avatar ... clearly I understand the command line paradigm.
It just doesn't fit well with Windows :)
I recognized it... I'm sure you do... but I think you make an error is assuming it is more appropriate in some OS's then in others. It is universally useful. A hundred years from now, I would be surprised if this were not true.

Beyond that, I'll remind you that windows admins use the command line too frequently to discount it's value.

Yes, linux has a far superior command line... that is why I said that MS would do well to improve the windows command line. However, despite the fact that it's inferior to linux in this regard, it is extremely useful... and most of the things you do in the linux command line can be done in the windows command line with the right added programs.


In large part this all windows needs to close this gap... update the CMD a bit and add a lot more command line aware programs. I found a lot of freeware programs for windows that accomplish most of this... it works well all things considered.
 
>Beyond that, I'll remind you that windows admins use the command line too frequently to discount it's value.

of couse, but then it is related to configuration options and not applications.

Bless you in your tenacity


I'm done here -- you can have the last word :)
 
>Beyond that, I'll remind you that windows admins use the command line too frequently to discount it's value.

of couse, but then it is related to configuration options and not applications.

Bless you in your tenacity


I'm done here -- you can have the last word :)
HEY don't be like! :p
Jobeard, you've personally helped me out with a lot of my questions here and it should come as no surprise that when I come here on some level I'm coming to pick YOUR brain.

So I respect your opinion and knowledge greatly. The command line is very useful for windows users and is a generally under appreciated interface. I remain a novice by your standards but I've personally found it able to solve a lot of problems that otherwise would require programming.

As to tenacity... you have no idea. :D <---- Teeth.
 
Hey, you're OK , I OK (sometimes with enough coffee :) )

I just can't move this discussion into the solution square you're seeking :)
 
If you're comfortable with commands and scripting, then Perl is a rich language for all kinds of 'programming'
I detest the grammar but as Perl is the primary CGI code for website forms processing,
it dawns upon me that you can easily solve the HD access across the network problem.
You have to write the logic, but the Perl libraries are full of free support code.

I have Perl loaded on my XP/Pro laptop (as well as Apache2) for website development
testing. Write and test locally and the upload to the website.
 
so... how long would the code have to be... just a guess... to get it to mount something on a remote system as a "fixed" disk?

I'll be learning this language from scratch, so I'd like to know how much time investment is required before final pay off...
 
so... how long would the code have to be... just a guess... to get it to mount something on a remote system as a "fixed" disk?
hum; smaller than a Mac Truck and larger than a bread box --- actually hard to tell.
I am investigating a package known as Ntfs-3g to see how well it might fit.
It's an abstraction later to allow Mapping Drives, and once mapped, normal I/O
could be used (I think!).

Like so many things, it's a house of cards to get all the requirements inline to perform
the prototype test. I'm playing with Cygwin at the moment ...

I'll be learning this language from scratch, so I'd like to know how much time investment is required before final pay off...
hum; not a good project to learn Perl :(

Let me play a bit; I'll see if I can get the NTFS package loaded and report back.
 
Let me play a bit; I'll see if I can get the NTFS package loaded and report back.
Any windows compatible file system would be fine... I don't know if less complex file systems are easier to emulate... if NTFS is easier then by all means, but if fat is easier it's the same to me.
 
jobeard PMed me this code so I thought I'd share it here in the spirit of community
Code:
#!C:\Perl\bin\perl

<< '*/';
    REQUIREMENTS:  Perl5
    
    the first line documents where Perl is installed
    invoke    ./sambaFile.pl  is the same as 
                  perl ./sambaFile.pl
        
    We use the perl library IO to provide 'handle' support
*/

use IO;

local $sampleFile1 = '/Downloads/file1.data';

local $mappedDir   = 'M://contents2.txt';           ## mapped to \\eMac\Jeff

## Sample PIPE to a simple command
local  $PWD = 'PWD';
    createPipe(*PWD, "pwd");
    readPipe(*PWD);
    
## Another, sample LS -l  (windows would be dir )
$PWD = 'LS';
    createPipe(*PWD, "ls -l C://Downloads/file1.data");
    readPipe(*PWD);
    
#open a local file and display
local  $DATA = "filedata";
    openFileRO(*DATA, $sampleFile1);    ## access it the 'natural' way
    readFile(*DATA);
    closeFile(*DATA);
    
#open a remote file and display
local  $DATA = "filedata";
    openFileRO(*DATA, $mappedDir);      ## access using <dl://>pathtofile
    readFile(*DATA);
    closeFile(*DATA);

## subroutines ##
sub openFileRO($$) {
    my ($handle, $path) = @_;
        print STDERR "\t opening $handle on $path...\n";
    open($handle, $path) or die "openFile $path failed; $!\n";    
}

sub readFile($) {
    my ($handle) = @_;
    my $buf;
    print STDERR "\t reading $handle ...\n";
    while (<$handle>) {
        print STDOUT  $_;
    }
   
}

sub closeFile($) {
    my ($handle) = @_;
    
    close($handle);
}

sub createPipe($$) {
    my ($handle, $cmd) = @_;
    print STDERR "\t opening $handle on $cmd\n";
    open ($handle, " $cmd | " ) or die "Pipe Failed; $!\n";
}

sub readPipe($) {
    my ($handle) = @_;
    my $buf;
    my $j = 0;
    print STDERR "\t readPipe $handle ...\n";
    while (<$handle>) {
              print STDOUT  $_;
    }
}

1;

good luck
 
Random thoughts

- in the old, old days, one might want to install a Cd on the local hard disk and run it from there (speed and convenience), but it might refuse to run. Maybe the programs detected and would only run from a removable drive? The point is, there were a number of program utilities published designed to do just that (hide from the OS exactly what type of drive it was). Maybe something on those lines is what you want? However, http://www.burnworld.com/software/utilties/virtual-drive.htm makes it clear that these things were implemented as a TSR (terminate and stay resident) program that hooked into the read/write channels. That has no place on todays PC's.

- Older, older than that, other programs regarded any drive from F: upwards as being a network, and it was oohherrr, no way! The answer to that was shuffle your drive letteres around and MAP a network drive really low i.e. D: or E:

I think that just perhaps, possibly, maybe moving your Cd/DVD drives up to X:,Y: and mapping this network drive down low, might work????
 
Status
Not open for further replies.
Back