分享c#写的 虚拟文件系统 开源库

https://github.com/FrozenCow/sharpfilesystem

SharpFileSystem

SharpFileSystem is a Virtual File System (VFS) implementation for .NET to allow access to different filesystems in the same way for normal files and directories.

Motivation

After looking a long time for a VFS for .NET, so that I could read files and directories in archives (zip and rar) the same way as any ordinary files and directories. I couldn't find any complete solution for this problem, so I decided to implement a VFS myself. Also what I didn't like in the ordinary filesystems was the path-system. It allowed relative paths (like ..), which can often lead to security issues without explicit checking. It allows referring to directories the same way as referring to files. This often leads to strange behavior, like copying a directory (source) to another directory (destination), here it is often vague whether the destination directory should be overwritten or if it should copy the source-directory inside the destination-directory.

Goals

• Using multiple types of filesystems (ie. zip, rar, ftp, etc) in the same way.
• A way to combine these systems to structure multiple parts of your program resources and configurations.
• A way to restrict or hide parts of your filesystem to parts of your program.
• A robust way of handling paths.

Features

At the moment the following filesystems are implemented:

• PhysicalFileSystem: gives access to the real operating system filesystem (uses System.IO of .NET/Mono).
• MemoryFileSystem: simulates a filesystem in-memory.
• SevenZipFileSystem: gives access to any 7-Zip supported archive.

There are also filesystems that alter the exposed structure of existing filesystems. These allow you to mix different systems together to get the desired file-structure:

• ReadOnlyFileSystem: Only allows read-operations on the wrapped filesystem.
• MergedFileSystem: Merges multiple filesystems into a single file-structure.
• FileSystemMounter: A unix-like mount system, which mounts other filesystems to a specified path.
• SubFileSystem: Allows you to create a filesystem from a directory of another filesystem and therefore restricts access to parent-directories.
• SeamlessSevenZipFileSystem: Allows access to 7-Zip archives as if they're directories.

Implementation

At the heart of the system there is the IFileSystem interface. This describes the operations that should be provided by every filesystem:

public interface IFileSystem : IDisposable
{
    ICollection<FileSystemPath> GetEntities(FileSystemPath path);
    bool Exists(FileSystemPath path);
    Stream CreateFile(FileSystemPath path);
    Stream OpenFile(FileSystemPath path, FileAccess access);
    void CreateDirectory(FileSystemPath path);
    void Delete(FileSystemPath path);
}

Normally in .NET/Mono we refer to files by their path coded as a string. This sometimes leads to inconsistencies, which is why I've created the type FileSystemPath to encapsulate the path in SharpFileSystem. There are operations that help create and alter the path, but the rules of using them are more strict, which creates a much more robust environment for the programmer:

• Independent of the OS, the directory-separator is always /.
• All paths always start with /. This means: there are no relative paths.
• All paths that refer to a directory end with /.
• All paths that refer to a file do not end with /.
• The path cannot be manipulated as a string, only new paths can be created through a small set of operations (likeSystem.IO.Path.Combine for .NET).

Some examples of using FileSystemPath:

Operation	Result
var root = FileSystemPath.Root	/
var mydir = root.AppendDirectory("mydir")	/mydir/
var myfile = mydir.AppendFile("myfile")	/mydir/myfile
myfile.AppendFile("myfile2")	Error: The specified FileSystemPath is not a directory.
mydir.ParentPath	/

https://github.com/nreco/nicnet/tree/master/src/NI.Vfs

Virtual File System for .NET (C#) Apache Commons VFS port.

---

NI.Vfs is based on Apache Commons VFS (C# port of V1) and adopted for .NET environment. Part of NIC.NET open-source library.

features

• Abstract filesystem API for accessing files by application logic
• Mature object model for representing filesystem domain (folders tree and file operations)
• Implementations: local filesystem, memory filesystem
• Free and open source (LGPL)

links

Nuget Package	NI.Vfs
Source code	NI.Vfs on GitHub
API Reference	NI.Vfs

how to use

1. Install NI.Vfs nuget package

2. using NI.Vfs;
   ...
   IFileSystem localFs = new LocalFileSystem("c:\\temp");
   var txtFile = localFs.ResolveFile("test1.txt");
   txtFile.CreateFile();

https://github.com/platformdotnet/Platform.VirtualFileSystem

Platform.VirtualFileSystem

Read the Platform.VirtualFileSystem wiki

A virtual file system for C#, .NET and Mono.

Platform.VirtualFileSystem provides a uniform, cross-platform and managed abstraction layer for file systems. It is similar to VFS features of various operating systems like Linux except it all runs in managed code. Features include:

• Support for Microsoft .NET and Mono.
• Unified addressing. All files and directories are addressed using URIs. No need to concern yourself with different path separators and naming schemes on different platforms.
• Support for layered URIs to support addressing of nested file systems (zip, overlayed and netvfs). Layed URIs are supported using square brackets. For example the URI to a.txt contained inside a zip archive located at C:\Test.zip is:zip://[file:/C:/Test.zip]/a.txt
• Very simple but powerful API for working with files. Normalisation of relative paths (paths containing "." and "..") is inbuilt at a low level and thus is supported by all providers. Support for extended attributes and alternate data streams are supported on Windows (NTFS) and supporting Unix file systems (ext2fs, xfs etc).
• Extensible file and directory services architecture (for example: IFileHashingService andIFileTransferService). All services implementPlatform.ITask meaning they can all run the background; are monitorable (percent complete, bytes transferred etc) and can be paused, or cancelled.
• Pluggable provider architecture makes adding new filesystems a breeze.
• Pluggable provider architecture makes extending existing file systems easy. Filters that can modify or wrap files/directories can be added usingINodeResolutionFilter. Operations on files can be intercepted and/or overidden usingINodeOperationFilter.
• Fully thread-safe.
• Easy to detect file system changes using C# events on IFile and IDirectory interfaces.
• Default cache provides strong object identity. Resolving the same path will return the same object instance as long as the file/directory is still referenced elsewhere.
• Support for defining managers and providers in code or declaratively within app.config or web.config.

Installation

Platform.VirtualFileSystem is available via nuget. You can search for Platform.VirtualFileSystem using the Visual Studio NuGet plugin UI or by typingInstall-Package Platform.VirtualFileSystem into the Visual Studio Package Manager Console. If you want zip support you should also install the zip provider usingInstall-Package Platform.VirtualFileSystem.Providers.Zip.

A package for those who don't use NuGet will be available in the future. In the mean time you can download the latest zip of the NuGet package direct from thenuget website. Note that you will also need the Platform.NET package.

Three assemblies are required for Platform.VirtualFileSystem: Platform.dll,Platform.Xml.Serialization andPlatform.VirtualFileSystem.dll. If you require zip support thenPlatform.VirtualFileSystem.Providers.Zip.dll andICSharpCode.SharpZipLib is also required. Platform.VirtualFileSystem will automatically load the zip provider if thePlatform.VirtualFileSystem.Providers.Zip.dll is located in the same directory asPlatform.VirtualFileSystem.dll.

Included FileSystem providers

Local Provider

Provides access to the concerete file sytems of the underlying operating system. Example URIs:

C:\Windows\Temp
file:///usr/local/src
file://c:/Windows/Temp

Web Provider

Provides read-only access to ftp and http file systems view the .NET HTTP WebRequest object. Example URIs:

http://www.github.com

View Provider

Create custom file systems rooted from a directory of any other file system. This is very useful for avoiding the use of absolute concrete file system paths. For example, you can mapD:\App\Data to a view accessible viaappdata://. All your code will be resilient to any changes to the underlying location of theappdata:// view. You could moveD:\App\Data to E:\App\Data or even to a non-local provider without breaking any existing code. Views also add security by ensuring code can't access files above the root of the view. Example URIs:

config:///A/B.txt
mycustomview:///A/B.txt

SystemInfo Provider

Similar to the /proc file system on Linux, the SystemInfo provider provides simple read-only access to environment variables and read-write access to the system clock. Access to more advanced operating system settings are planned for the future.

systeminfo:///EnvironmentVariables/TEMP
systeminfo:///SystemClock/CurrentDateTime

Overlayed Provider

Create a file system made up of the merged view of one or more file systems.

overlayed://[file:///tmp/a;file:///tmp/b]/c

Temp Provider

A provider accessible via the temp:// scheme that provides access to temporary storage (usually backed by/tmp on Unix andC:\Windows\Temp on Windows)

temp:///tempfile1.dat
temp:///tempfile2.dat

MyComputer Provider

Provides a simple and cross-platform consistent view of the disks on a system.

mycomputer://C
mycomputer://D
mycomputer://C/Windows
mycomputer://CDROM-1/i386
mycomputer://FLOPPY-1/GAME/LEMMINGS

DataFile Provider

Provides a simple interface for load/saving of objects serialized into files (seeDataFileTests.cs). RequiresPlatform.VirtualFileSystem.DataFile.dll.

Network VFS Provider

Exposes all VFS file systems over TCP. Many services are supported natively (for exampleIFileHashingService would be executed remotely on the server). RequiredPlatform.VirtualFileSystem.Network.*.dll.

netvfs://hostname[file:///usr//]/local/src

Zip Provider

Provides a virtualised view of zip files. Both readonly and random readwrite support zip files has been supported since version 1.0.0.45. You can also directly create a zip file from an existing directory usingZipFileSystem.CreateZipFile.

zip://[file:///home/tum/Test.zip]/Directory/Textfile.txt

Usage Examples

// Get a directory
var localDir = FileSystemManager.Default.ResolveDirectory("C:/Windows");

// Create a view with the scheme 'windows'
var windowsFileSystem = localDir.CreateView("windows");
var system32 = windowsFileSystem.ResolveDirectory("System32");

// Will output: windows:///System32
Console.WriteLine(system32.Address);

// Add the file system to the default FileSystemManager
FileSystemManager.Default.AddFileSystem(windowsFileSystem);

var windowsNotepad =  FileSystemManager.Default.ResolveFile("windows:///notepad.exe");

// Will output: True
Console.WriteLine(windowsNotepad.Exists);

var root = localDir.ResolveFile("..");

// Will output: file://C:/
Console.WriteLine(root.Address);

var localNotepad = dir.ResolveFile("notepad.exe");

// Will output: True
Console.WriteLine(localNotepad.Exists);

// Will output: /Windows/notepad.exe
Console.WriteLine(root.Address.GetRelativePathTo(localNotepad.Address));

// Will output: ../..
Console.WriteLine(root.Address.GetRelativePathTo(localNotepad.Address));

Refer to the Platform.VirtualFileSystem.Tests project for more examples.

Configuring default FileSystems

The default file system manager (FileSystemManager.Default) contains all the standard file system providers except for Network and Zip. If you want to custom define what is available or add views or custom providers, you can extend the IFileSystemManager interface, construct and populate a separate StandardFileSystemManager or define file systems within yourapp.config orweb.config. Please reference app.config from the tests project to see an example of how to do the later.

License

Platform.VirtualFileSystem is released under the terms of the new BSD license as documentedhere. Zip support is provided by a separate assembly (Platform.VirtualFileSystem.Providers.Zip) which depends onSharpZipLib which is licensed under the GPL with an exception that permits commercial use.

Contributing

Platform.VirtualFileSystem was written quite a few years ago and has been recently updated to modern C#. It was written in a time before type inference, automatic properties and lambda expressions so if you see legacy cruft please don't hesistate to update it.

More

Read the Platform.VirtualFileSystem wiki

http://vfs.codeplex.com/

• Follow (33)
• Subscribe

Project Description

VFS abstracts arbitrary hierarchical resources as a virtual file system, and provides access via a simple yet extensible and powerful API. As a true abstraction, it aims at solving a number of problems:

• Truly transparent file access allows you to switch the used file system (e.g. from local storage to the cloud) without changing any code.
• Custom authorization and authentication of file system requests based on your own business rules.
• Custom providers can be easily implemented to expose any resources the way you want (e.g. virtual folders containing files depending on a user's identity)
• Providers can define arbitrary meta data for files, folders, and permissions (e.g. to plug in quota management)
• Seamless remoting of file systems if needed.
• Reliable file transfers locally and over the wire with streamed and/or segmented down-/uploads.
• Management and synchronization of concurrent read/write requests.
• File event management (phase 2)

The most recent build can always be downloaded from here:
http://www.hardcodet.net/uploads/projects/vfs/vfs.zip

Editor's note: This project is currently in beta, so there's no production-ready content available here yet, but I'm grateful for feature requests and wish lists. I also plan to release updates and the first bits viahttp://www.hardcodet.net, so you can just subscribe to the blog's feed in order to keep up-to-date.



File System Providers

VFS's provider model abstracts hierarchical resources as a file model. Here's a few scenarios:





VFS 1.0 will come with a set of built-in providers, but hopefully, community contributions will be available as well. Currently planned providers:

• Local File System, optionally limited to a given folder (implemented, see snippets below)
• WCF/REST façade that allows to transparently access any VFS provider via a service interface (partly implemented, see snippet below)
• Cloud Storage
• FTP (priority 2)

Security

VFS will expose a pluggable security mechanism used for client authentication and authorization of file system requests. It will leverage the current offerings of the .NET framework, and also support Windows Identity Foundation (WIF) for service oriented scenarios.


Auditing

It is be possible to plug in an auditing manager which will receive auditing messages on configurable levels to simplify tracing and auditing of file system requests and incidents. A default auditing manager that just uses a logging mechanism will be part of the VFS core framework.


Clients

A set of clients will be provided that can be used as a starting point to integrate VFS into your applications:

• RIA Client (Silverlight) using WCF
• Desktop client (WPF) that uses different providers to access local or remote file systems.
• ASP.net file download manager (operating on expiring download tokens)

The API

VFS is currently in early alpha but will hopefully progress fast enough so the first bits can be published. The client API, however, is already quite stable:

Every operation is an independent invocation on a file system provider ( IFileSystemProvider interface):

//expose the contents of a given folder as a file system using a provider that operates on the local file system
IFileSystemProvider provider = new LocalFileSystemProvider(@"C:\MyData");

//we can get the root through its qualified name or a dedicated method (recommended)
VirtualFolderInfo root = provider.GetFileSystemRoot();
foreach (VirtualFileInfo file in provider.GetFiles(root))
{
  //access meta data
  Console.Out.WriteLine("Root folder contains file " + file.Name);

  //...read the file data (there's helper classes to deal with streams)
  Stream data = provider.ReadFileContents(file.FullName);

  //...or perform operations (delete, overwrite, move, copy)
  provider.DeleteFile(file.FullName);
}

Dealing with file system providers is greatly simplified through wrapper classes - VFS provides a very simple API to browse and manage the file system:

//get root folder
VirtualFolder root= VirtualFolder.CreateRootFolder(provider);
//create child folder on root level
VirtualFolder childFolder = root.AddFolder("folder1");

//upload a local file's data to the FS - overwrite it if it already exists
Stream stream = ...
VirtualFile file = childFolder.AddFile("foo.txt", stream, true);

This snippet gets text files in all folders on the root level and deletes them

VirtualFolder root= VirtualFolder.CreateRootFolder(provider);
foreach(VirtualFolder childFolder in root.GetFolders())
{
  foreach(VirtualFile file in childFolder.GetFiles("*.txt"))
  {
    VirtualFileInfo fileInfo = file.MetaData;
    Console.Out.WriteLine("Deleting file " + fileInfo.Name);
    file.Delete();
  }
}

VFS also comes with a WCF/REST service that service-enables arbitrary file system providers (just plug in a file system into the service). The service is complemented by a client library that is a VFS file system provider itself. Accordingly, the API is exactly the same when accessing remote data. The only change is the different provider implementation:

//the provider will access the service as configured in app.config
IFileSystemProvider provider = new RemoteServiceFileSystem();

//get root folder
VirtualFolderInfo root = provider.GetFileSystemRoot();

//create two folders on the root level
VirtualFolderInfo f1= provider.AddFolder(root, "folder1");
VirtualFolderInfo f2= provider.AddFolder(root, "folder2");

//copy the first folder into the second one (this operation will be performed on the server)
provider.MoveFolder(f1, "/folder2/copy");

Last edited May 14, 2010 at 6:04 PM by phsumi, version 20