Re: Perl to mount a virtual filesystem on Windows?
by Bloodnok (Vicar) on Dec 13, 2008 at 14:16 UTC
|
| [reply] [d/l] [select] |
Re: Perl to mount a virtual filesystem on Windows?
by BrowserUk (Patriarch) on Dec 13, 2008 at 14:44 UTC
|
I'm pretty certain that it is impossible to write a device driver in perl. DDs have to operate in a very restricted environment and be fully reentrant. And having written a few, I'll tell that it is a distinctly non-trivial task.
If you simply want a gooey interface to ftp, just spread some jam on your keyboard (Sorry, my mind wandered :), it would be far quicker and easier to grab one of the myriad freeware apps kicking around.
Or even use your browser. Most of them will allow you to type an ftp:// url into the address bar
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re: Perl to mount a virtual filesystem on Windows?
by isync (Hermit) on Dec 13, 2008 at 14:23 UTC
|
The basic idea is to write a script (or app, with the help of Wx::Perl) that, once fired up, registers an additional device drive and enables me to have convenient access to a FTP server via Net::FTP.
Any ideas on how to do that? | [reply] |
|
|
Net::FTP can speak directly to any FTP-server without you having to register an additional device driver.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
| [reply] |
|
|
not exactly referring to my idea...
| [reply] |
|
|
|
|
Re: Perl to mount a virtual filesystem on Windows?
by Fletch (Bishop) on Dec 13, 2008 at 23:46 UTC
|
Another approach if you've got a Linux box handy might be to re-export a FuSE filesystem (see curlftpfs for example, or roll your own with Fuse) which does the FTP part. Just make that visible as CIFS via samba and you'd be good.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] |
Re: Perl to mount a virtual filesystem on Windows?
by GrandFather (Saint) on Dec 13, 2008 at 23:01 UTC
|
A quick glance at the Dokan library documentation suggests to me that you could access the dokan.dll using Win32::API and thus provide a file system written in Perl. It seems to me that it would be a lot of work!
The dokan authors strongly recommend that you use a Virtual Machine when you develop file system applications - that sounds like very sage advice to me!
Perl's payment curve coincides with its learning curve.
| [reply] |
|
|
Thanks for the hint, I will have a look into it! But as you remarked that it would be *a lot* of work, I do not feel so inclined anymore to try it...
| [reply] |
|
|
| [reply] |
|
|
|
|
Re: Perl to mount a virtual filesystem on Windows?
by isync (Hermit) on Sep 07, 2009 at 17:23 UTC
|
Today, weeks later, I had another try to see what's the status of the Win32::Dokan bundle. The results are disappointing:
- dokan.h has advanced to revision 26, but the .xs code used by Win32::Dokan does not use the new API introduced a few revisions earlier.
- dokan-0.4.2.1238 x86 2008/12/31 is out (don't know if that was the version I was using earlier) but I still does not "magically solve problems"...
- Win32::Dokan now advanced to a tagged revision _0.03_1, but problems remain, a compile agains dokan.h r7 and r26 failed on strawberry perl
Some code is untouched for over six months now. I hope the Win32::Dokan developer reads this here and will invest a bit more work...
My process was:
1. download the dokan release, extract the zip and do the .msi installer, to C:\Programs\DokanLibrary.
2. extract the Win32::Dokan .tar.gz archive to a directory
3. Download the dokan.h, rev7 into the Win32::Dokan directory
4. go to console and do > perl Makefile.PL -l "C:\Programs\DokanLibrary"
5. > dmake (ran okay)
6. > dmake test (lots of errors, "can't locate Win32/Dokan/Const.pm" among others)
A few minutes later I tried another process and was SUCCESSFUL!:
1. download the latest trunk tar.gz SVN revision of Win32:Dokan (as the tagged version misses some files, for example Const.pm...)
2. extract trunk.tar.gz into a directory and cd into it
3. Edit Makefile.PL manually to hardcode/'make sure' it the path variable points to a working dokan.h and we don't need to mess with the -l option (in my case: my $dokan_library = "C:/Programme/DokanLibrary"; - this is the dokan.h that comes with the .msi installer, I did not try to again use the dokan.h, in any revision, from the Dokan google code page this time!)
4. reboot, so Dokan is really working (low level system driver, so this makes sense)
5. perl Makefile.PL - ok -dmake - ok - dmake test - ok - dmake install - ok! | [reply] [d/l] |
Re: Perl to mount a virtual filesystem on Windows?
by isync (Hermit) on Mar 30, 2009 at 22:16 UTC
|
Today, I had the nerve to revisit this Dokan/userspace-fs thread and tried to compile Win32-Dokan under StrawberryPerl - with little success.
My environment:
-strawberry-perl-5.8.9.0
-Win32-Dokan-0.02_1
-dokan.h (revision 7)
This combination is the one I had the most luck with, anyway 'perl Makefile.PL' then 'dmake' resulted in lots of warnings and some fatal errors:
Combinations of this strawberryperl plus different revisions of Win32-Dokan from SVN and dokan.h more or less gave comparable results.
I am too novice in regards to compiling stuff to make any sense of that. Anyone here who feels inclined to helping me out?
| [reply] [d/l] |
|
|
Hi isync, thanks for your report!
(I'm tofjw. Sorry I don't have an account on this site.)
1. Many warnings.
Warnings about SyncExec are reported because first argment
of SyncExec is decalared as:
typedef int (Func_t)(SV* self, void* pParam);
but passed function (ex. DP_WriteFile) is declared like below.
static int DP_WriteFile(void* self, void* pParam)
(conflict of SV* and void*)
Yes, it's a bug, but I think it's harmless.
2. Not resolved symbols (_gmtime64_s and _localtime64_s)
They are thread safe 64bit variant of gmtime (and localtime)
in MSVC runtime. If they are not in your C runtime, you can
re-write using gmtime and localtime. Because in this version
of Win32-Dokan, execution of callbacks are serialized using
Win32 event object.
First, replace functions in Dokan.xs like following and try
build.
static void set_file_time(LPFILETIME pFileTime, time_t t)
{
*pFileTime = 0;
}
static time_t get_file_time(const FILETIME* pFileTime)
{
return 0;
}
Timestamp will be NOT correct, but you can confirm script
works or not.
| [reply] [d/l] [select] |
|
|
Thank you for getting back! I will try another compile-run as soon as possible.
Update:
I actually managed to get a version together that threw only warnings on dmake. A subsequent dmake -i got me to a runnable version of Win32::Dokan.
Anyway, running examples/mirror.pl resulted in an error: "&Win32::Dokan::constant not defined at mirror.pl line 17" with line 17 being
14: my $fs = Mirror->new("D:/");
15: my $mounter = Win32::Dokan::Mounter->new({debug_mode => 1,
16: use_std_err => 1});
17: $mounter->mount('W', $fs);
Testing other combinations: this SVN version lacks a META.yml (the sourceforge version contains it) and using it with the modifications in Dokan.xs gave among warnings an error: "In function `set_file_time': Dokan.xs:296: error: incompatible types in assignment".
I hope this helps and you feel motivated for another release/patch on SVN: trunk that works more seamlessly with newer dokan.h. | [reply] [d/l] |
|
|
|
|
|