Hi,
  I finally get a working executable of encfs for Windows (encfs is a
Linux/Mac encrypted file system in userspace using fuse). If anybody
is interested and have any hints, comments or suggestion see page at
http://members.ferrara.linux.it/freddy77/encfs.html

freddy77

Freddy any problems using it w/Windows 7 64bit?

On Feb 2, 6:05 am, Frediano Ziglio <fredd...@gmail.com> wrote:

I don't know... the 64bit issue I reported in TODO is not related to
operating system bits but to C APIs.

2011/2/17 SHA2YB <aaron.hito...@gmail.com>:

There are no problems with 64-bit Vista based operating systems. Howeve with that said you will need to obtain a digital signature for these os's.  Otherwise Microsoft will not allow the driver to be installed. You can place your machine in test mode and use a test certificate for testing purposes.

Regards,
Mark Carrier

www.myvdrive.net

Sent from my iPhone

On Feb 21, 2011, at 6:59 AM, Frediano Ziglio <fredd...@gmail.com> wrote:

Dokan works fine on 64bit Windows 7. (Im using DokanDotNet in my
DokanDiscUtilsBridge project)

On Feb 21, 9:19 am, Mark Carrier <m...@carrierlabs.com> wrote:

Thanks for taking on this project.  I've be waiting for this for a
while.

I just downloaded and tried your binary.  I installed Dokan 0.6.0,
then ran encfs.  I chose the "preconfigured paranoia" mode.
First, the program just hangs there.  If verbose is turned on, it
says
"22:32:56 (Interface.cpp:165) checking if nameio/null(1:0:0)
implements nameio/nu
ll(1:0:0)"  I don't know if this is normal.
Second, I can create a directory in the plain directory.  I can
create
a file as well.  But I can't actually go into the directory or open
the file.
mkdir a
cd a
"The system cannot find the path specified."
notepad a.txt
more a.txt
"Cannot access file C:\Users\XXX\Desktop\erase\plainb\a.txt"
dir
 Directory of C:\Users\XXX\Desktop\erase\plainb
The parameter is incorrect.
⌂      <DIR>          .
The parameter is incorrect.
      <DIR>          ..
02/26/2011  10:39 PM    <DIR>          a
02/26/2011  10:39 PM                 4 a.txt
               1 File(s)              4 bytes
               3 Dir(s)               0 bytes free
Any idea what is going on?

On Feb 2, 6:05 am, Frediano Ziglio <fredd...@gmail.com> wrote:

Under WinXP works correctly. Try to add -o debug to enable all debug
informations. This won't fix the problem but at least we should see
what's going on.

The program does not hung, it keeps working providing crypted
directory (I agree it should say something about it :) when encryption
will work correctly I'll write a simple gui interface).

I'll be on holiday from 2 to 24 March so if you don't see reply don't worry.

Regards
  Frediano Ziglio

2011/2/27 Poeter <brendan....@gmail.com>:

Thanks!
I've include the debug info below.

When I do a "mkdir c":

###Create 0009
CreateDirectory : \c
###Cleanup 0009
Cleanup: \c 0

###Close 0009
Close: \c 0

When I do a "cd c", which fails with "The system cannot find the path
specified."

###Create 0010
   CreateDisposition 1
CreateFile : \C
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2
###Create 0011
OpenDirectory : \
###FindFiles 0011
FindFiles :\
index from 0
FileMatch? : . (c,0,0)
FileMatch? : .. (c,0,0)
FileMatch? : a (c,0,0)
FileMatch? : c (c,0,0)
  =>return single entry
index to 1
###Cleanup 0011
Cleanup: \ 0

###Close 0011
Close: \ 0

###Create 0012
   CreateDisposition 1
CreateFile : \C
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2

When I do a "dir", which gives back "The parameter is incorrect." for
the . and .. directories:

###Create 0016
   CreateDisposition 1
CreateFile : \*
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2
###Create 0017
OpenDirectory : \
###FindFiles 0017
FindFiles :\
index from 0
FileMatch? : . (*,0,0)
  =>return single entry
index to 1
index from 1
FileMatch? : . (*,1,0)
FileMatch? : .. (*,1,1)
  =>return
FileMatch? : a (*,1,2)
  =>return
FileMatch? : c (*,1,3)
  =>return
FileMatch? : b (*,1,4)
  =>return
index to 5
index from 5
FileMatch? : . (*,5,0)
FileMatch? : .. (*,5,1)
FileMatch? : a (*,5,2)
FileMatch? : c (*,5,3)
FileMatch? : b (*,5,4)
  STATUS_NO_MORE_FILES
###Cleanup 0017
Cleanup: \ 0

###Close 0017
Close: \ 0

###Create 0018
OpenDirectory : \
###QueryVolumeInfo 0018
GetDiskFreeSpace
###QueryVolumeInfo 0018
GetDiskFreeSpace
###Cleanup 0018
Cleanup: \ 0

###Close 0018
Close: \ 0

It looks like the encfs implementation does not support the fact that both directories and files can be opened through CreateFile.

IMO it is really somewhat unfortunate that Dokan splits the directory logic out to separate directory functions. This is not how Windows handles in internally, and Dokan isn't able to fully isolate you from this.

Effectively what it means right now is that inside CreateFile you may be opening either a directory or a file. And inside Create/OpenDirectory it is always a directory.

Windows actually also can indicate to the driver that a directory is not allowed to be opened, however, Dokan does not currently pass this information along to the FS implementation... I have a fixed this in a test project of myself, as it can cause some unexpected behavior in applications.

- Jurjen

-----Oorspronkelijk bericht-----
Van: dokan@googlegroups.com [mailto:dokan@googlegroups.com] Namens Poeter
Verzonden: maandag 28 februari 2011 22:04
Aan: Dokan
Onderwerp: [Dokan] Re: encfs windows port progress

Thanks!
I've include the debug info below.

When I do a "mkdir c":

###Create 0009
CreateDirectory : \c
###Cleanup 0009
Cleanup: \c 0

###Close 0009
Close: \c 0

When I do a "cd c", which fails with "The system cannot find the path
specified."

###Create 0010
   CreateDisposition 1
CreateFile : \C
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2
###Create 0011
OpenDirectory : \
###FindFiles 0011
FindFiles :\
index from 0
FileMatch? : . (c,0,0)
FileMatch? : .. (c,0,0)
FileMatch? : a (c,0,0)
FileMatch? : c (c,0,0)
  =>return single entry
index to 1
###Cleanup 0011
Cleanup: \ 0

###Close 0011
Close: \ 0

###Create 0012
   CreateDisposition 1
CreateFile : \C
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2

When I do a "dir", which gives back "The parameter is incorrect." for
the . and .. directories:

###Create 0016
   CreateDisposition 1
CreateFile : \*
        AccessMode: FILE_READ_ATTRIBUTES
        ShareMode: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
        Disposition: OPEN_EXISTING (3)
CreateFile status = -2
###Create 0017
OpenDirectory : \
###FindFiles 0017
FindFiles :\
index from 0
FileMatch? : . (*,0,0)
  =>return single entry
index to 1
index from 1
FileMatch? : . (*,1,0)
FileMatch? : .. (*,1,1)
  =>return
FileMatch? : a (*,1,2)
  =>return
FileMatch? : c (*,1,3)
  =>return
FileMatch? : b (*,1,4)
  =>return
index to 5
index from 5
FileMatch? : . (*,5,0)
FileMatch? : .. (*,5,1)
FileMatch? : a (*,5,2)
FileMatch? : c (*,5,3)
FileMatch? : b (*,5,4)
  STATUS_NO_MORE_FILES
###Cleanup 0017
Cleanup: \ 0

###Close 0017
Close: \ 0

###Create 0018
OpenDirectory : \
###QueryVolumeInfo 0018
GetDiskFreeSpace
###QueryVolumeInfo 0018
GetDiskFreeSpace
###Cleanup 0018
Cleanup: \ 0

###Close 0018
Close: \ 0

--
You received this message because you are subscribed to the Google Groups "Dokan" group.
To post to this group, send email to dokan@googlegroups.com.
To unsubscribe from this group, send email to dokan+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dokan?hl=en.

Il giorno lun, 28/02/2011 alle 13.04 -0800, Poeter ha scritto:

Mmm... in this case is correct... C is not c! However I don't understand
where this problem came... why 7 command line capitalize names ??

Does Dokan/encfs pass correct flags to programs?? Or should I support
case insensitive? Is not that easy for encfs... encfs crypt even
filenames which are very different if case changes. This would require
to decode all file names and check not crypted names. For folders with a
lot of entries this slow down a lot.

freddy77

Yoou need to decide which way to go with the Filenames - upper or lower case
- in your code, and then send the correct flags to the drive type flags
reported by the Dokan Driver to the OS
i.e. (Stolen from my Liquesc implementation) - see the enlarged font part,
that shows the Win32 flags:

public int GetVolumeInformationProxy(IntPtr rawVolumeNameBuffer, uint
rawVolumeNameSize, ref uint rawVolumeSerialNumber,
          ref uint rawMaximumComponentLength, ref uint
rawFileSystemFlags, IntPtr rawFileSystemNameBuffer, uint
rawFileSystemNameSize, ref DOKAN_FILE_INFO fileInfo)
      {
         try
         {
            byte[] volume = Encoding.Unicode.GetBytes(options.VolumeLabel);
            int length = volume.Length;
            byte[] volumeNull = new byte[length + 2];
            Array.Copy(volume, volumeNull, length);
            Marshal.Copy(volumeNull, 0, rawVolumeNameBuffer,
Math.Min((int)rawVolumeNameSize, length + 2));
            rawVolumeSerialNumber = volumeSerialNumber;
            rawMaximumComponentLength = 256;

*            //#define FILE_CASE_SENSITIVE_SEARCH      0x00000001
            //#define FILE_CASE_PRESERVED_NAMES       0x00000002  *
            //#define FILE_UNICODE_ON_DISK            0x00000004
            //#define FILE_PERSISTENT_ACLS            0x00000008  //
This sends the data to the Recycler and not Recycled
            // See
http://msdn.microsoft.com/en-us/library/aa364993%28VS.85%29.aspx for
more flags
            //
            // FILE_FILE_COMPRESSION      0x00000010     // Don't do
this.. It causes lot's of problems later on
            // And the Dokan code does not support it
            //case FileStreamInformation:
            //            //DbgPrint("FileStreamInformation\n");
            //            status = STATUS_NOT_IMPLEMENTED;
            //            break;
            rawFileSystemFlags = 0x0f;

            byte[] sys = Encoding.Unicode.GetBytes("DOKAN");
            length = sys.Length;
            byte[] sysNull = new byte[length + 2];
            Array.Copy(sys, sysNull, length);

            Marshal.Copy(sysNull, 0, rawFileSystemNameBuffer,
Math.Min((int)rawFileSystemNameSize, length + 2));
            return 0;
         }
         catch (Exception ex)
         {
            Log.ErrorException("GetVolumeInformationProxy threw: ", ex);
            return -1;
         }
      }

hi ;)
i´ve tried this nice port and have a problem with getting it to work
on win 7 64 bit
i can write to the crypted folder but when i try to read windows says
the path does not exist :|
i did anything like explained
so any suggestions?
thx in advance! :)

On 2 Feb., 15:05, Frediano Ziglio <fredd...@gmail.com> wrote:

Hi,
unfortunately, also the latest version from 2011-03-29 does not work
with Win7 x64.
All created files or directories are created internally with upper
case, so there is no access to files/directories containing lower
cases.
Example:
mkdir XXXX  -> it works
mkdir xxx -> directory not found

No thanks,

I prefer postgresql mounted as a filesystem ;)

--
Cordiali saluti,
Valeriano Cossu

Regards,
Valeriano Cossu

ph: (0039) 346 2187419
http://www.valerianocossu.com
skype: valerianocossu

2011/3/1 Smurf IV <smurf...@gmail.com>:

...

I tried 1, 2 and 3 with no success :(
Also you have to consider that NTFS set both flags. It seems that
PRESERVED_NAMES means that file system store upper case in upper case
and lower using lower so a Unix system should set this flag but why
NTFS which is not case sensitive (if you open "foo" it open even "FOO"
and if you try to create a "foo" directory and there is a "FOO"
directory operation fails) set this flag too ??
However it seems that mounting my file system on a new drive works
even on Windows 7... don't know why!

Frediano

A bug in the current version 05/11/2011.  First, thanks so much for
the work.  I'm following you work because I really would like to run
encfs with my dropbox as well.  Now, on to the bug:

Using Windows 7x64, when I rename a file to the name of an already
existing file, the file is automatically overwritten!  There is no
error message or warning.  Just puff, your old file is gone.

When I rename a folder to the name of an already existing folder, this
results in an error about folder not found.  This error message is
okay, but the correct Windows 7 error message is about merging a
folder.

For clarification, I did use a drive letter as the plain directory, as
suggested by our documentation.

On May 11, 4:17 pm, Poeter <brendan....@gmail.com> wrote:

Il giorno mer, 11/05/2011 alle 16.18 -0700, Poeter ha scritto:

Should work now. Let me know.

Regards
  Frediano

Works very well on Windows & Dropbox! thanks.

It would be great if you could add some of the command line options
available under linux, e.g --extpass

--extpass is the only option I removed. But others works. To implement
gui I used a pipe to send the password to encfs.exe, something like

echo my_password | encfs.exe c:\crypt c:\plain

bye
  Frediano

2011/7/7 Florian <lau.flor...@googlemail.com>:

Thanks for the idea! Yet, the syntax was not fully correct. You need
to add an "-S" at the end to have encfs read the password from
standard input, see http://pwet.fr/man/linux/commandes/encfs

So my fully automatic mounting script looks like this:

###########################################
rem @echo off
set crypt=C:\Dropbox\.dropbox_enc
set decrypt=C:\Dropbox_Enc
set pw=Your_Password
echo %pw%|encfs %crypt% %decrypt% -S
###########################################

Maybe you wanna add this (and the other command line options) to the
readme or your homepage?

Cheers.

On 8 Jul., 14:31, Frediano Ziglio <fredd...@gmail.com> wrote:

My only problem with that script is that the EncFS windows port stays
active rather than starting a background process.

I have 2 EncFS folders in my Dropbox I want to mount automatically and
don't like the idea of a command prompt window staying open (or 2
since I'd need to use that auto script twice).

I created a VBScript file to do this for me.
###################
' Script to automate mounting of EncFS volumes
'
' This script must be run from the same directory as
' the encfs.exe file.
'
MountVolume "C:\Documents and Settings\user\My Documents\My Dropbox
\.encfs1", "X:", "dummy_password1"
MountVolume "C:\Documents and Settings\user\My Documents\My Dropbox
\.encfs2", "Y:", "dummy_password2"

Sub MountVolume(crypt, decrypt, pw)
  Set WshShell = WScript.CreateObject("WScript.Shell")
  Dim Cmd
  Cmd = "%COMSPEC% /c echo " & pw & "|""" & WshShell.CurrentDirectory
& "\encfs.exe"" """ & crypt & """ """ & decrypt & """ -S"
  WshShell.Run Cmd, vbHide
End Sub
###################

This fires open 2 new shells but hides them.  The only way to unmount
these volumes is now to kill the process in Task Manager, but I am ok
with this.

On Jul 12, 3:52 am, Florian <lau.flor...@googlemail.com> wrote:

I realize this is an old thread, but be careful with this solution. I got
this working apparently very nicely and relied heavily on it for most of my
day-to-day data. But then some files started randomly becoming inaccessible
to encfs on Linux. It’s been about a year so I don’t remember the details
of the problem, but long and short, many files became unreadable eventually
in any version of encfs and therefore the data in them lost. I had to
restore unencrypted versions from backup (fortunately I continuously backup
my dropbox folders!), but I did still lose some data.

I had no other file corruption on any other OS, outside of encfs
complaints. Chkdsk and fsck reported no problems. I run clean and minimal
systems and engage in no "risky" behavior.

I'm did not invest time debugging the problem so I can't be sure it would
happen to me again and/or to anyone else, but given that nothing else
unusual was going on (other than running complex beta-quality software to
support a cross-platform layered file system), it seems a logical
conclusion to exercise care.

At minimum, use some kind of continuous versioned backup solution against
your decrypted mount point. And/or, don't store data that would kill
someone if corrupted!

I'd also recommend BoxCryptor by now... Works perfectly on Mac and Windows.

Am Mittwoch, 2. Februar 2011 15:05:31 UTC+1 schrieb Frediano Ziglio: