Make sure that files that are siblings of directories, are reported as files

[nickvergessen]

Without the patch, the two files are reported to be a collection:

...
	<d:response>
		<d:href>/col/col/test.txt</d:href>
		<d:propstat>
			<d:prop>
				<d:resourcetype>
					<d:collection/>
				</d:resourcetype>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
...
	<d:response>
		<d:href>/dir/child.txt</d:href>
		<d:propstat>
			<d:prop>
				<d:resourcetype>
					<d:collection/>
				</d:resourcetype>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
...

Reported in nextcloud/server#5543 Proposed patch is from @blancjerome I just wrote the test case and cleaned it up a bit...

[PVince81]

Travis failures, not sure if related:

1) Sabre\HTTP\SapiTest::testSendLimitedByContentLengthStream

TypeError: stream_copy_to_stream() expects parameter 3 to be integer, string given

/home/travis/build/fruux/sabre-dav/vendor/sabre/http/lib/Sapi.php:93

/home/travis/build/fruux/sabre-dav/vendor/sabre/http/tests/HTTP/SapiTest.php:158

[DeepDiver1975]

Who has to power to merge? @evert (sorry to wake you up) @staabm @DominikTo ?

[staabm]

I cannnot merge it as long as the build isnt green.

Just restarted the build.

I cannot say whether this fix is correct. Will take your word for it.

[DominikTo]

Changelog needs update, too.

[DeepDiver1975]

Changelog needs update, too.

@nickvergessen can you please take care? THX

[nickvergessen]

I just saw that you do forward merges? So should I send my PR against 3.2 and add it to the changelog in the 3.2 block?

[DeepDiver1975]

I just saw that you do forward merges? So should I send my PR against 3.2 and add it to the changelog in the 3.2 block?

@DominikTo @staabm you are deeper involved here - what is the correct workflow? THX
(Or is that documented and I did not read properly? 😉 )

[staabm]

in case this is considered a bugfix you should merge/cherry-pick it into the lowest/oldest branch which is applicable for it (e.g. oldest yet maintained one) and merge into newer ones.

IIRC if your git fu is great enough you can do this via commandline, no matter what/where the Pull Request is pointing to. its easier for the maintainer when the base branch of this PR is already pointing to the right branch.

[nickvergessen]

Rebased onto 3.2 (version we are using) since I didn't find info what is still supported

3.1 is EOL since June 2017: http://sabre.io/dav/install/

[nickvergessen]

3.1 is EOL since June 2017: http://sabre.io/dav/install/

So it seems to be correct

[DeepDiver1975]

and now cherry-pick to master and 3.3? with/without pull request?

[blancjerome]

Thanks guys for what you're doing ... I just found and corrected a bug, but didn't thought it was so painfull to merge it in the release :) 2017-10-10 13:26 GMT+02:00 Thomas Müller <[email protected]>:

…

and now cherry-pick to master and 3.3? with/without pull request? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#982 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcmytUtk3Hjwh_tdSFyBZDeg1n6NkH8Hks5sq1RcgaJpZM4OW0kY> .

[nickvergessen]

They seem to just merge it forward, so

• git checkout 3.3
• git merge --no-ff 3.2
• git checkout master
• git merge --no-ff 3.3
• git push origin 3.3 master

[DeepDiver1975]

Done

[nickvergessen]

I think you merged 3.2 in master instead of 3.3 ;)

anyway thanks for getting this forward :)

[evert]

Just fyi, the 3.3 branch was intended to just displace the 3.2. It's been backward compatible, but it has a few small improvements. So if you were to drop 3.2 and do a release of the 3.3 branch, things should be fine.

[LorbusChris]

Can we get a new release with this PR?

[staabm]

for a new release we might also update the bundled sabre/xml

https://github.com/sabre-io/xml/releases/tag/2.1.0