New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected file names being saved causes data loss #7509
Comments
Please post the transcript from the log drawer (⌘-L). |
Replying to [7509 chris deeming]:
The setting in Preferences for other uploads is not taken into account for edits. When editing files we always use the temporary upload name to avoid writing to a file that is currently being served from a web server for example. Also the point is actually to avoid data loss if the upload is interrupted. |
I did a quick testing running SabreDAV on my local machine and could not reproduce the issue. |
Please file a bug with XenForo. Make sure to include the transcript from the log drawer with the |
A little bit too quick to close this ticket. Quite disappointed. The only thing that has changed in the setup is Cyberduck 4.4. Essentially Cyberduck has introduced "a feature" or some other change that breaks backwards compatibility with other applications. Here's the log drawers: This is the output from 4.4 (not working):
And this is the output from 4.3.1 (working):
|
And exactly what do you expect XenForo to do about it? You must consider that XenForo is a database driven application and therefore it has constraints on various things for many reasons. Specifically in this case, they don't allow anything other than a-z, A-Z, 0-9 _ or . in their template names, so the hyphenated string you append on the end causes an error. Finally, they don't allow template names longer than 50 characters. The title field in the xf_template table is VARBINARY(50). It's unreasonable to expect them to change these as those constraints were included for a reason. And despite myself bypassing those constraints by skipping the title validation in their code and increasing the field to VARBINARY(500), I instead get a template name that's garbage and the original template name is no longer there. |
Replying to [comment:6 chris deeming]:
No offense. We try to make a triage quickly with tickets to avoid piles of unresolved issues. |
Replying to [comment:6 chris deeming]:
That is true only if the feature introduced would not be standard (WebDAV RFC) compliant. |
Replying to [7509 chris deeming]:
I can't see this in the transcript posted. Do you have a screenshot of this error response? |
Replying to [comment:7 chris deeming]:
It is not feasible to impose such internal design limitations as the WebDAV protocol does not have a restriction of the URI length (RFC 2616). |
As a temporary workaround, disable the use of the temporary filename option using the hidden setting
|
Ok. When you put it like that, I guess the change is reasonable. No offense taken at the closing of the ticket. It's just all too often people out there like to get tickets out of the door with the minimum amount of work possible, but I see that isn't happening here. Thank you for the workaround. I will try it and report back. Can I make a simple change request that perhaps solves the problem satisfactorily for both parties? Could the hidden setting above be made a configurable option in Preferences? I have to say, I've been using Cyberduck extensively and it works perfectly. Before the temporary filename feature, I have never once experienced any issues relating to saving files from an external editor. I can understand the reasons for this feature, though, and would be happy for it to be on by default, as long as I can understand the risks and turn it off. I have asked XenForo if they will consider any fixes, but this is unlikely. As much as their template system do not adhere to WebDAV standards, it isn't feasible, necessarily, to expect them to. Primarily templates are edited directly from the Admin CP. WebDAV is a functionality for power users, but it was by no means written solely for WebDAV compatibility. But that helps neither of us :) I will try that workaround now, thank you so much for taking the time to assist further with the issue. |
The temporary workaround works great, thank you. |
To summarize.
|
I believe this issue to be affecting all OS platforms.
I use a WebDAV interface which is provided by SabreDAV in the forum software XenForo for editing XenForo templates.
If I create a template named webdav_test, I can find it in Cyberduck as webdav_test.html. I can then launch it in my external editor (PHP Storm 7). Cyberduck confirms the file has been downloaded. I then make an edit and Save. Cyberduck confirms the file has been uploaded.
What happens next is the template I am working on disappears.
It transpires that the error being thrown by XenForo is that the filename contains invalid characters. After bypassing that check, the error being thrown is the length of the filename is too long (over 50 characters).
After preventing these errors from stopping the save process, I can confirm the filename being saved is:
webdav_test9.html-5f13b83a-80eb-4cce-8b73-4fbbec7a96c1.html
The original file, webdav_test9.html has disappeared.
If I do not bypass the first two errors, actually nothing gets saved and the original file is deleted completely which unfortunately causes data loss.
I initially presumed this was due the new feature:
[Feature] Upload with temporary name when saving from external editor
However this is off by default and whether that is on or off, the result is the same.
It is worth noting that this has all been working as expected until 4.4 was released.
At risk of digressing...
I am currently finding it difficult to use either version 4.3.X or 4.4.X with PHP Storm 7 as an external editor.
I have it configured so that double clicking a file opens it in the external editor. It seems that doing so causes Cyberduck to download the file but PHP Storm doesn't open it. The issue seems worse in 4.3.X and slightly better in 4.4.X (if you forgive the data loss part! :-) )
The text was updated successfully, but these errors were encountered: