winterleaf / winterleaf-webdavsharp.sqlexample Goto Github PK

I setup the project (MS SQL 2012 on a Win2012 VM), deployed the DB's and added root folder (with dummy user as I didn't found another/cleaner way).

Now, I have the WebDAVSharp.SQL Server running and trying to connect to htpp://localhost:8880 through chrome. When connecting, the WebDAVSharp.SQL.exe throws two errors:

1. Unhandled Exception: System.Data.SqlClient.SqlException: Server 'ADSI' could not be found in sys.servers
2. The value 'NULL' can not be written to the 'IsGroup'-column. The column doesnt accept 'NULL' values. Error while UPDATE.

I cant explain myself the first error cause I dont know what the ADSI server could be in the sys.servers table, maybe some Active Directory ?

The second one seemingly results from an update statement to the SecurityObject table which specifies that 'IsGroup' should be NULL.

Am I just missing a server link, link to Active Directory or somthing or is this realy a kind of bug ?

In WebDavSqlStoreDocument constructor, when creating a new document the initial file size is set to 1 instead of zero, this causes errors in the Litmus tests.

The fix is to simply correct the line as _filesize = lastmod?.Size ?? 0; .

Hey there,
I just cloned this repository, added a reference to the nu-get package of WebDAVSharp.Server and tried to build. Now, I have like 300 errors of missing directives or assembly references.
(For eg.: In WebDAVSharp.Data:SqlStoreFileInfo the base class 'WebDavFileInfoBase' is missing, and I cant find any existance of it (nor in this and neither in the WebDAVSharp.Server repo).

Is it possible this repository is outdated and doesnt work with newer version of WebDAVSharp.Server or am I missing something obvious ?

After i copy any file to a folder, i get the "file already exists" dialog.
Some who has the same issue? Is there an workaround?

I setup the project (MS SQL 2012 on a Win2012 VM), deployed the DB's and added root folder (with dummy user as I didn't found another/cleaner way).

Now, I have the WebDAVSharp.SQL Server running and trying to connect to htpp://localhost:8880 through chrome. When connecting, the WebDAVSharp.SQL.exe throws two errors:

1. Unhandled Exception: System.Data.SqlClient.SqlException: Server 'ADSI' could not be found in sys.servers
2. The value 'NULL' can not be written to the 'IsGroup'-column. The column doesnt accept 'NULL' values. Error while UPDATE.

I cant explain myself the first error cause I dont know what the ADSI server could be in the sys.servers table, maybe some Active Directory ?

The second one seemingly results from an update statement to the SecurityObject table which specifies that 'IsGroup' should be NULL.

Am I just missing a server link, link to Active Directory or somthing or is this realy a kind of bug ?

When a lock is taken, a Lock-Token header should be emitted in the response, with the <uuid:urn:[guid]> value.

To resolve this error, add the following line in WebDavLockMethodHandler, line 251:

context.Response.AppendHeader("Lock-Token", "<" + locktoken.ToLockToken() + ">");

This fixes litmus test locks#6.

The lock mechanism uses a Guid to identify the lock owner, derived from the Active Directory authentication. I think that probably the two should be decoupled and the store layer should only know about a generic user string token. This would fix some other locking issues in the litmus tests.
Unfortunately I cannot provide a patch for this at this time, but I'll leave this as an idea probably worth sharing.

The lock token is emitted as (urn:uuid:[GUID]), but later it is parsed as if it were (<[GUID]>).

In file WebDavExtensions.cs, the method GetLockTokenIfHeader should be changed as follows:

public static Guid? GetLockTokenIfHeader(this IHttpListenerRequest request)
{
	if (!request.Headers.AllKeys.Contains("If"))
		return null;

	string ifHeaderValue = request.Headers["If"];
	int posLastColon = ifHeaderValue.LastIndexOf(':');
	int posUrnClose = ifHeaderValue.IndexOf('>');
	string t = ifHeaderValue.Substring(posLastColon + 1, posUrnClose - posLastColon - 1);
	return new Guid(t);
}

When a folder is created, then deleted, then another one with the same name gets created, the storage returns the deleted object instead of the correct one.

The fix is simple enough: in WebDavSqlStoreItem.cs, line 80, add an && !d.IsDeleted clause.

This error was discovered while trying to run the litmus test suite on the component.

In Folder_Ext.cs, method CopyFileHere, line 391 reads

File newFile = File.Create(destination.pk_FolderId, file.Name, user.UserProfile, true);

while it should be

File newFile = File.Create(destination.pk_FolderId, destinationName, user.UserProfile, true);

Therefore, the code creates new files with the same name of the copied one.
This error has been found using litmus' copymove tests.

In WebDavSqlStoreItemLock, line 256, requestDocument gets instantiated as a new XmlDocument.
Later in WebDavLockMethodHandler, this empty document is used to retrieve some data and obviously fails.

From this comment, it seems that a valid XmlDocument is to be filled in by RefreshLock method:

//Refresh lock will ref us back the original XML document which was used to request this lock, from
//this we will grab the data we need to build the response to the lock refresh request.

So to fix this error I added the following lines after line 256 of file WebDavSqlStoreItemLock.cs:

var lockinfoNode = requestDocument.CreateElement("D", "lockinfo", "DAV:");

var lockscopeNode = requestDocument.CreateElement("D", "lockscope", "DAV:");
if (inst.LockScope == WebDavLockScope.Exclusive)
	lockscopeNode.AppendChild(requestDocument.CreateElement("D", "exclusive", "DAV:"));
else
	lockscopeNode.AppendChild(requestDocument.CreateElement("D", "shared", "DAV:"));

lockinfoNode.AppendChild(lockscopeNode);

var locktypeNode = requestDocument.CreateElement("D", "locktype", "DAV:");
if (inst.LockType == WebDavLockType.Write)
	locktypeNode.AppendChild(requestDocument.CreateElement("D", "write", "DAV:"));

lockinfoNode.AppendChild(locktypeNode);

var lockownerNode = requestDocument.CreateElement("D", "owner", "DAV:");
lockownerNode.InnerText = info.OwnerId.ToString();

lockinfoNode.AppendChild(lockownerNode);

requestDocument.AppendChild(lockinfoNode);

It is pretty crude but does the job and fixes litmus test locks#8.

The Enabled parameter in WebDavSqlStoreCollectionFactory is set but never used.

The fix is to add at the beginning of method GetCollection (line 41) the following lines:

if (!Enabled)
    return new WebDavSqlStoreCollection(parentCollection, path, rootPath, rootGuid, Store);

This allows better troubleshooting of any issue during testing.

In class WebDavSqlStoreDocument, the method OpenWriteStream does not invalidate the document cache - it is necessary to supply the instance of the document factory at line 86:

return f?.OpenWriteStream(PrincipleFactory.Instance.GetPrinciple(FromType.WebDav), ItemPath, WebDavSqlStoreDocumentFactory.Instance);

Unfortunately this is not enough to fix the problem, since WebDavSqlStoreDocumentFactory.InvalidateDocumentPath is used as a dynamic method and class WebDavSqlStoreDocumentFactory is declared as internal thus the method binding fails at runtime. Therefore it is also necessary to change WebDavSqlStoreDocumentFactory declaration to public.

This fixes issues in the Litmus tests.

Right now the storage layer only manages a handful of properties, mostly the ones related to filesystem properties. This makes most of the props tests of the litmus suite fail, because they try to set and retrieve custom properties. Fixing this would require revamping the properties' table storage and changing the handling of the special filesystem properties. Unfortunately I can't provide a patch for this at this time, but I'll leave this here as an idea worth exploring.

When opening a document using a ms-ofe hyperlink (i.e. ms-word:ofe|u|https://dgrob-lscorcia:8443/Luca/test.docx ), the server has to specify an additional header in the OPTIONS method to allow successful opening by Office applications.

Therefore, in file WebDavOptionsMethodHandler, after line 41, the following line should be added:

context.Response.AppendHeader("MS-Author-Via", "DAV");

This makes Office applications send LOCK and UNLOCK commands to the server and play nice with the WebDav implementation.

I noticed that your readme isn't realy 'well-formatted' as well complete. Therefore I rewrote the readme for better formatting and integrity (I included steps that was neccessary for me to run this project).

Would be glad if you would maybe update your readme according to my changes.
Here's the source of my readme.

Preview of updated README as GIST