Closed lonnietc closed 1 year ago
On windows use -o uid=-1
to be able to access the drive.
Strange in that is still does not work:
I tried:
.\memfs.exe -o uid=-1
Memfs does not implement Statfs
and so FUSE reports zeroes for total and free space. However MEMFS should work from the command line.
You can add an implementation of Statfs
with whatever space you want to report to overcome this.
Hello,
I actually understand that there is no Statfs and that the Golang version reports zeros for total and free space.
In testing, I ran the installed version of memfs-x64.exe from the winfsp-1.12.22339.msi which mounts and runs just fine.
PS C:\Program Files (x86)\WinFsp\bin> .\memfs-x64.exe -m x:
memfs -t -1 -n 1024 -s 16777216 -m x:
The service memfs has been started.
NOTE: The above will allow for copy-past files in the virtual drive.
But, with the compiled cgofuse memfs.exe version:
PS D:\FPfile\WinFSP\cgoFuse\cgofusec\Test> .\memfs.exe -o uid=-1 H:
The service memfs has been started.
NOTE: The above will not allow for copy-past files in the virtual drive.
So then, in the C++ version there are the "-n 1025" and "-s 16777216" options for the MaxFileNodes and MaxFileSize from the help menu:
PS C:\Program Files (x86)\WinFsp\bin> .\memfs-x64.exe -h
usage: memfs OPTIONS
options:
-d DebugFlags [-1: enable all debug logs]
-D DebugLogFile [file path; use - for stderr]
-i [case insensitive file system]
-f [flush and purge cache on cleanup]
-t FileInfoTimeout [millis]
-n MaxFileNodes
-s MaxFileSize [bytes]
-M MaxDelay [maximum slow IO delay in millis]
-P PercentDelay [percent of slow IO to make pending]
-R RarefyDelay [adjust the rarity of pending slow IO]
-F FileSystemName
-S RootSddl [file rights: FA, etc; NO generic rights: GA, etc.]
-u \Server\Share [UNC prefix (single backslash)]
-m MountPoint [X:|* (required if no UNC prefix)]
The service memfs has failed to start (Status=c0000001).
but in the Golang (cgofuse) version memfs.exe, I did not see and MaxFileSize and MaxFileNodes or similar options and it's help system says:
PS D:\FPfile\WinFSP\cgoFuse\cgofusec\Test> .\memfs.exe -h
usage: memfs mountpoint [options]
-o opt,[opt...] mount options
-h --help print help
-V --version print version
FUSE options:
-d -o debug enable debug output (implies -f)
-f foreground operation
-s disable multi-threaded operation
WinFsp-FUSE options:
-o umask=MASK set file permissions (octal)
-o FileSecurity=SDDL set file DACL (SDDL format)
-o create_umask=MASK set newly created file permissions (octal)
-o create_file_umask=MASK for files only
-o create_dir_umask=MASK for directories only
-o uid=N set file owner (-1 for mounting user id)
-o gid=N set file group (-1 for mounting user group)
-o rellinks interpret absolute symlinks as volume relative
-o dothidden dot files have the Windows hidden file attrib
-o volname=NAME set volume label
-o VolumePrefix=UNC set UNC prefix (/Server/Share)
--VolumePrefix=UNC set UNC prefix (\Server\Share)
-o FileSystemName=NAME set file system name
-o DebugLog=FILE debug log file (requires -d)
WinFsp-FUSE advanced options:
-o FileInfoTimeout=N metadata timeout (millis, -1 for data caching)
-o DirInfoTimeout=N directory info timeout (millis)
-o EaTimeout=N extended attribute timeout (millis)
-o VolumeInfoTimeout=N volume info timeout (millis)
-o KeepFileCache do not discard cache when files are closed
-o LegacyUnlinkRename do not support new POSIX unlink/rename
-o ThreadCount number of file system dispatcher threads
-o uidmap=UID:SID[;...] explicit UID <-> SID map (max 8 entries)
With all of this in mind, what am I missing here to give a size parameter to the cgofuse version? Thanks
The cgofuse memfs is a simple sample and does not implement all necessary operations for Windows. There is no command line option that you can give to overcome this problem. Instead you must supply your own implementation of Statfs
.
I see. So then what you are saying is that unlike the C++ version of memfs, the Golang version it not fully functional. That I did not know as I thought that it was supposed to be a functioning version mimicking the C++ memfs version, but in Golang.
Seems like the hubfs is the only complete non-sample complete version that I have really gotten to work with WinFSP in Golang and everything else related is just unfinished examples.
Guess that I will have to look into the Statfs implementation.
Thanks.
The purpose of the cgofuse project is to provide access to FUSE from Go. The purpose of the example file systems is to test the cgofuse implementation.
As such the missing Statfs
method is actually intentional to check that things continue to work reasonably well even when Statfs
is missing (early development versions of cgofuse would fail more spectacularly when Statfs
was missing).
I understand now and truly appreciate you clarifying things.
I was proceeding from the aspect of memfs being a full working version that could be used as a template to work with as it was supposed to compile and work on all of the platforms. I was going to use it to learn from, but also know that it was a viable working version as well since I am still delving into Golang while coming from a C++ world but needed something that would cross-compile as the other component that I want to mix with WinFSP (cgofuse) is already in Golang and is a type of bittorrent that I will connect with a CGOFUSE filesystem frontend for a mountable virtual disk drive.
Also, I did look into possibly using you objfs or hubfs (which I like hubfs the most) but the AGPL license does not work for the project that I am trying very hard to piece together with different libraries, so I had to fall back on your memfs, or seek some other solution.
Thanks again
Hello,
I have built the Golang memfs.exe but if I run it without any command line options then it will not allow me to add any files.
Seems like I need some CLI options to allocate some space and it does not do it by default.
Did I miss something?