wlmaps: Downloading a map depends on map name, not map filename

Bug #1615364 reported by kaputtnik
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Widelands Website
Won't Fix
Low
Unassigned

Bug Description

Two strange things:

1. One creates a map, gives the map a name in editor map options but saves it with a different name. F.e.:

- Map name (editor options): 'First test'
- Filename: 'Atlanteans mission'

After uploading the map on the website the map name "First test" is shown up. When downloading you will get a map called 'First test.wmf', not the real filename 'Atlanteans mission.wmf'. Not a big problem but confusing.

2. Because the name of a map (set in editor map options) could contain special characters (like a slash) this could lead into misbehavior. F.e.:

- Map name (editor map options): 'map 64/64'
- Filename: 'map 64x64' (saving with a slash isn't possible in editor)

When uploading on the Website the Mapname is shown as "map 64/64" which seems to be correct, but trying to download result in a downloaded file called '64.wmf'.

I think we should deliver the map file with his real filename, not the name given in editor map options.

Tags: map
Revision history for this message
kaputtnik (franku) wrote :

Of course it could also be confusing when a map is shown up with name 'First test' and by download it is saved as 'atlantean mission.wmf'. Maybe we have to display also the filename on the homepage to clarify.

Revision history for this message
SirVer (sirver) wrote : Re: [Bug 1615364] Re: wlmaps: Downloading a map depends on map name, not map filename

I think using the Name Displayed on the website makes sense - why should we use the uploaded name which could be completely non related like temp1.wmf.

The specials characters are an issue though - and they are not addressed by using the uploaders file name: what is valid on one os is not necessarily on another. So I suggest we replace non ascii and dangerous characters in the map name when creating the file name.

> Am 21.08.2016 um 18:37 schrieb kaputtnik <email address hidden>:
>
> Of course it could also be confusing when a map is shown up with name
> 'First test' and by download it is saved as 'atlantean mission.wmf'.
> Maybe we have to display also the filename on the homepage to clarify.
>
> --
> You received this bug notification because you are subscribed to
> Widelands Website.
> https://bugs.launchpad.net/bugs/1615364
>
> Title:
> wlmaps: Downloading a map depends on map name, not map filename
>
> Status in Widelands Website:
> New
>
> Bug description:
> Two strange things:
>
> 1. One creates a map, gives the map a name in editor map options but
> saves it with a different name. F.e.:
>
> - Map name (editor options): 'First test'
> - Filename: 'Atlanteans mission'
>
> After uploading the map on the website the map name "First test" is
> shown up. When downloading you will get a map called 'First test.wmf',
> not the real filename 'Atlanteans mission.wmf'. Not a big problem but
> confusing.
>
> 2. Because the name of a map (set in editor map options) could contain
> special characters (like a slash) this could lead into misbehavior.
> F.e.:
>
> - Map name (editor map options): 'map 64/64'
> - Filename: 'map 64x64' (saving with a slash isn't possible in editor)
>
> When uploading on the Website the Mapname is shown as "map 64/64"
> which seems to be correct, but trying to download result in a
> downloaded file called '64.wmf'.
>
> I think we should deliver the map file with his real filename, not the
> name given in editor map options.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands-website/+bug/1615364/+subscriptions

Revision history for this message
kaputtnik (franku) wrote :

> I think using the Name Displayed on the website makes sense
Agreed

> why should we use the uploaded name which could be completely non related like temp1.wmf.
I believe such a name will never be used:

- A file name is much important for a user. Having maps called temp[1...x].wmf one will never find the map he is searching for.
- When saving a map in editor the suggested file name is build of of the name in options. If it is "No Name" (default) then the suggested file name is "No Name".
- When saving a map without modifying the name in options, the map get saved containing the file name as map name in options. If the file name is "my first map" then the map name in options is turned into "my first map"

> what is valid on one os is not necessarily on another. So I suggest we replace non ascii and dangerous characters in the map name when creating the file name.

As i know the save dialogue of editor does this exactly right now. It is afaik impossible to give a map a file name containing special characters (couldn't find the merge or the code yet). Why should we implement the same thing twice?

As i understood you want to replace some characters of a maps name to become a valid file name. So there will be three names in the end:
"map 64x64.wmf" (original file name) -> "map 64/64" (name of map shown on the website) -> "map 64_64.wmf" (delivered file name)

What if a maps name is something like "Jundlina asks: "Is there a place to live?"" This would become to: "Jundlina asks_ _Is there a place to live__.wmf". The uploaded file name given by the author is maybe just: "Jundlina asks.wmf"...

Currently the fields in map options could also be empty (bug 1544474). Uploading a map with empty "name" field is possible, but leads to a crash on the website everytime the maps page gets opened (ok, another bug)

I think the file name of a map is the only valid thing we have. I am in favor of making things not to complicated: Show the maps name on the website like it is now, but add the original filename to the details table (File name: map 64x64.wmf) and deliver the map with the original file name.

Revision history for this message
SirVer (sirver) wrote :

> I believe such a name will never be used

I used such names all the time when designing maps - even more so before the editor got undo/redo.

> Why should we implement the same thing twice?

We have to since there is no trusted path between editor and website. We have no guarantees that maps come out of the Editor and have not been changed. In fact there is at least one map uploaded to the website that has a README file inside the ZIP that is the wmf file - so the user zipped the map manually and did not let the map editor do it. Scenario maps actually *have* to be edited outside of the editor to add scripting - it is quite possible that a user also changes the elemental file then and changes the name.

> Show the maps name on the website like it is now, but add the original filename to the details table (File name: map 64x64.wmf) and deliver the map with the original file name.

I think this is fine but I would suggest that we add a super conservative check on the filename and reject it in the forms validation if it contains anything that is not uncontroversial. I would only allow "a-zA-z0123456789_", not even space. The user can then still choose the filename, but they have to adhere to stricter rules.

Revision history for this message
kaputtnik (franku) wrote :

I don't understand why the content of the zipped file should affect the file name :-S

If the content is changed there is nothing we could do (except a check in wl_map_info returning a "suspicious" error when something is unusual, like added unknown files).

Your last suggestion is meant to be a check for uploading or downloading? Doesn't allowing space will surely confusing on upload. When downloading a file it is no problem, imho.

Revision history for this message
SirVer (sirver) wrote :

> I don't understand why the content of the zipped file should affect the file name :-S

why not? if you download "Rick Ashley - Never gonna give you up" from the iTunes store, you would reasonable expect that the file name is called "Rick Ashely - Never gonna give you up.mp3", or not? Apple probably ingested it as 983afg983safde.mp3 or something, but as a user you do not expect that. If I download a map "The long path - version 2" (which is the name that comes from the "elemental" file in the widelands zip) from the widelands page, I'd follow the same logic and expect the name to be represented in the file.

> Your last suggestion is meant to be a check for uploading or downloading?

For uploading - I would try to make it impossible to upload maps that might be problematic in downloading on any system. That way, the original author can choose how to fix the problem she likes best.

Revision history for this message
kaputtnik (franku) wrote :

Ah, now i understand. Thanks :-)

Making a really save filename isn't an easy task it seems. I have just read: http://stackoverflow.com/questions/295135/turn-a-string-into-a-valid-filename-in-python

Revision history for this message
SirVer (sirver) wrote :

I would probably go with this answer from the SO you posted: http://stackoverflow.com/a/295152/200945 - it is most restrictive, but I consider this a good thing in this regard.

Revision history for this message
GunChleoc (gunchleoc) wrote :

How about adding an extra input field for the file name when uploading, prefilled from the map's name? This way, the user will have some control - illegal names should still be rejected though, with a possibility for the user to fix, or an autofix.

Revision history for this message
kaputtnik (franku) wrote :

> How about adding an extra input field for the file name when uploading, prefilled from the map's name?

No, i think this too complicated (and not file name safe regarding allowed characters). When a player saves a map for uploading, he may think that this name is used for downloading (i would think so). Providing an additional field for the map name (for download) is imho superfluous, at least because this is well done in the editor when saving a map.

This is really dependent on personal use case. One save's maps with "test_01" others with the (potentially shortened) name of the map. Personally i try to give files an appropriate name when storing them. The current behavior of the editor fits my use case :-) And that's the reason why i think downloading of a map should result in the same file name which is used for uploading. Just because the editor provides a file name dependent of the map name.

But i don't know how to handle different use cases on the website. Maybe reject file names which are not corresponding to the map name (give a hint: "Your maps name does not fit with the given file name. Please change the maps name or the file name and try again.")? This may prevent also something like https://wl.widelands.org/forum/topic/1992/

This is independent of a safe filename on up/downloading. This could be managed internally, f.e replace spaces, or special characters, with underscores.

Revision history for this message
GunChleoc (gunchleoc) wrote :

> Providing an additional field for the map name (for download) is imho superfluous

Agreed, I proposed an additional field during upload, not during download ;)

And of course the file name needs to be checked in any case.

Revision history for this message
kaputtnik (franku) wrote :

I think consensus is to deliver a map with his original file name (given by the user in editor). If we provide the original file name for download, the file name for upload and download is equal (except making it char safe).

Maybe i am thinking too complicated again :)

Revision history for this message
GunChleoc (gunchleoc) wrote :

Since a picture says more than a thousand words, I'm attaching a screenshot of an image upload that I programmed somewhere else. It has a "Rename Image:" field where the user can change the filename to something else during upload. We would have 2 such fields, one for the map name, and 1 for the file name, ideally prefilled from the map file that the user is trying to upload. This way, the user won't have to rename the map file on hard disk before the upload.

The filename field could have some explanatory text as to which characters are legal, plus we do an automatic cleanup in any case to be safe.

Revision history for this message
kaputtnik (franku) wrote :

> We would have 2 such fields, one for the map name, and 1 for the file name,

So if all options are filled out we will have at least 4 names of one map:
Nr. 1 and 2 given when saving a map: Name given in map options and a (maybe different) file name
Nr. 3 and 4 given in the upload form for file name and map name

> ideally prefilled from the map file that the user is trying to upload.

This data could only be used if a map has been uploaded yet. How will you otherwise get the map name (given in map options)? The prefilled file name could only be displayed with some javascript coding (executed in the users browser)

Additionally all things are much complicated:

Beside there are several maps saved on the server which are not available for download, if a maps file name already exist on the server, django changes the name to a name containing random chars. F.e. If a file name 'foo.wmf' already exists, the new uploaded file will become a name 'foo_j8kl65.wmf'

Providing the file name for download may result in unexpected results then. As long as i think/investigate this i feel the current solution is better (deliver the file with the name from maps options). We have just to create a safe file name ... hmmm

Revision history for this message
kaputtnik (franku) wrote :

Wrong wording: "As long ..." -> "As longer ..."

Revision history for this message
GunChleoc (gunchleoc) wrote :

Yep, this sounds quite complicated... maybe start with implementing the check for the safe filename, which we will need in any case?

If a map name already exists, we could add the version number and/or author name to the filename first, and only if all else fails something random?

Revision history for this message
kaputtnik (franku) wrote :

The best thing would be to add the row number from the table in the database corresponding to this map. This number is always different and always valid. I just have to figure out how this could be implemented the best way.

Revision history for this message
GunChleoc (gunchleoc) wrote :

+1 to #17

kaputtnik (franku)
Changed in widelands-website:
importance: Undecided → Low
kaputtnik (franku)
tags: added: map
Revision history for this message
GunChleoc (gunchleoc) wrote :
Changed in widelands-website:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.