This PR

• [x] uses lower-case for the package name in composer.json

💁‍♂️ Following an update of composer to 1.8.1, the following message is emitted when running related composer commands

Deprecation warning: require-dev.mikey179/vfsStream is invalid, it should not contain uppercase characters. Please use mikey179/vfsstream instead. Make sure you fix this as Composer 2.0 will error.

For reference, see https://github.com/composer/composer/releases/tag/1.8.1.

Added constant for the BLOCK filetype in vfsStreamContent.

Added new file: vfsStreamBlock

vfsStreamBlock is an extension of vfsStreamFile to represent a block device in the virtual filesystem, much the same way block devices are actually represented.

Added method to get a new block device in vfsStream.

Added a case for block devices in vfsStreamAbstractVisitor.

If there are any other requirements needed for this to be merged upstream please let us know, block device support is something that we found beneficial for our testing purposes.

As some might have noticed this project needs some updates to ensure it will work seemlessly with future versions of Composer and probably PHP as well. Also, there are several issues which are now open for quite some time without progess from my side. Unfortunately, I‘m lacking the time to take care of this and if I‘m honest the motivation isn‘t there either. Some have provided pull requests to tackle issues, but I‘m not comfortable simply accepting them without thinking about them properly.

Therefore I think it‘s time to hand this project over to new maintainers. If you are interested in becoming a maintainer please comment below. To ensure the project continues properly I‘d like if suggested maintainers see support by other users of the project, e.g. by +1 their comment, so this project doesn‘t run in a situation like certain Node modules. Also, I‘d be willing to support new maintainers in case of questions regarding the project for a couple of months to make sure they get a good understanding of the project.

If you have any other suggestions regarding the topic please feel free to comment as well.

From https://code.google.com/p/bovigo/issues/detail?id=24

What steps will reproduce the problem? To reproduce it, Ive use the interactive console (php -a)

php > require 'vfsStream.php';
php > vfsStreamWrapper::register();
php > mkdir('vfs://just/a/path',0777,true);
php > set_include_path('vfs://just/a');
php > $a = stream_resolve_include_path('path/unknownFile.php');
PHP Warning:   No such file or directory in .../vfsStreamWrapper.php on line 658
PHP Stack trace:
PHP   1. {main}() php shell code:0
PHP   2. stream_resolve_include_path() php shell code:1
PHP   3. vfsStreamWrapper->url_stat() .../vfsStreamWrapper.php:0
PHP   4. trigger_error() .../vfsStreamWrapper.php:658

What version of the product are you using? On what operating system? Version 0.8.0 (from SVN) with PHP5.3 on Ubuntu 10.10

Please provide any additional information below. Maybe this has something to do with #3?

Feature to test fopen() error cases, to simulate race conditions on fopen() that is when a readable file becomes unreadable on fopen() instantly, for example to simulate a file-system failure.

Proposition of proper flock implementation in vfsStream. Things done:

• each flock call should firstly release lock for current handler, so operations on just one file handler should be always successful
• file with exclusive lock on one handler can't be exclusively locked on other file handler
• file with shared lock on one handler can't be exclusively locked on other file handler
• file with exclusive lock on one handler can't be shared locked on other file handler
• you can make multiple shared locks using multiple file handlers
• added some additional tests

When using vfsStream::create(), the VFS is re-initialized each time. This is IMHO unexpected behaviour, as "create" is related to creating directories and files, not setting up the whole filesystem.

I propose to add a check to create() if the VFS has been set up, and then re-use that root, otherwise initialize it as it is currently.

I'm using PHP Unit in Windows If you try to mock the file system with vfsStream and open the mocked file with curl you get an error cannot represent a stream of type user-space as a STDIO FILE* In Linux everything is ok.

Tested with PHP 5.6.30

A testcase which works fine with for example php 5.6.x fails under php 7.0. is_writable() for a directory returns false for some reason. Doing a stat() on that directory returns the attached values. I expected that for example mode might be set wrong - but that imho looks okay as well.

array(26) { [0]=> int(0) [1]=> int(0) [2]=> int(16893) [3]=> int(0) [4]=> int(0) [5]=> int(0) [6]=> int(0) [7]=> int(0) [8]=> int(1449405664) [9]=> int(1449405664) [10]=> int(1449405664) [11]=> int(-1) [12]=> int(-1) ["dev"]=> int(0) ["ino"]=> int(0) ["mode"]=> int(16893) ["nlink"]=> int(0) ["uid"]=> int(0) ["gid"]=> int(0) ["rdev"]=> int(0) ["size"]=> int(0) ["atime"]=> int(1449405664) ["mtime"]=> int(1449405664) ["ctime"]=> int(1449405664) ["blksize"]=> int(-1) ["blocks"]=> int(-1) }

Just to mention it: I'm using vfsStream 1.6.1. I saw there were some fixes lately.

From https://code.google.com/p/bovigo/issues/detail?id=25

It would be nice if a vfsStreamFile object can lock itself. With this feature it would be possible to test if a file is locked or not. The PHP stream API supports the method stream_lock, but this isn't implemented yet(in vfsStream).

http://php.net/manual/de/streamwrapper.stream-lock.php

Since I think 2.0 is still a bit away judging by #181, should there be another 1.6.x release with at least the 7.4 compat changes that were made recently?

Is there anything else we'd like to backport from the master branch?

/cc @bovigo/vfsstream

All of the documentation and reference implementations I can find (e.g. Drupal's core tests) use vfsStream methods extensively to mock test fixtures.

But given that the whole point of this library is to mock a functional filesystem, shouldn't best practice be to use native filesystem methods when mocking fixtures? This decouples the choice of filesystem (real, vfs, or something else) from the business logic of fixture setup and is a heck of a lot more concise. For instance:

// Using vfsStream methods.
$root = vfsStream::setup();
vfsStream::newFile('acquia-pipelines.yml')
  ->at($root)
  ->withContent(file_get_contents('acquia-pipelines.yml'));

// Using native filesystem methods.
$root = vfsStream::setup();
copy('acquia-pipelines.yml', $root->url());

These seem functionally identical to me, except the latter is a lot more concise and easier to maintain. Is there any reason one should prefer using vfsStream methods?

touch() checks permissions only when it creates a new file (see also #107). Touching an existing object succeeds even when its permissions should not allow to:

$root = vfsStream::setup('root');
$file = vfsStream::newFile('test', 0)->at($root);
var_dump(touch($file->url())); // Should be FALSE and issue a warning, but actually succeeds

vfsStreamWrapper::stream_metadata() does not implement any permission checks.

Bumps actions/cache from 2 to 3.0.11.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps actions/checkout from 2 to 3.1.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Given that the file system is virtual, and as I understand fairly independent of the underlying system, it would seam it's possible to set a custom directory separator.

I have a usecase.

I develop an application that's supposed to work both on windows and Unix, so I need to write tests for / as separator and \ as well. In order to test it, I run two docker containers, one based on debian, one on windows.

If vfsStream supported both kinds of separators, I could test all my code without need for docker at all.

Welp, here we go again! The v1.6.x-dev version available via Composer now has support for PHP 8.2 nightly (which is currently in development). We have added PHP 8.2 to our CI testing on the v1.6 branch and will maybe keep things functional while 8.2 is in development. Once PHP 8.2 hits RC status, then we'll work on fixing any remaining issues before the final release.

If you're developing for PHP 8.2 and run into issues with vfsStream, report them here!

As always, thank you for streaming with vfsStream 📂