Ticket #8212 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

Etoys saving fails for non-ascii project names

Reported by: bert Owned by: etoys
Priority: blocker Milestone: 8.2.0 (was Update.2)
Component: etoys-activity Version: not specified
Keywords: 8.2.0:+ joyride-2390:- Cc: marco, tomeu
Action Needed: package Verified: no
Deployments affected: Blocked By:
Blocking:

Description

It fails sometimes - but I caught a log even though #6391 is still not resolved. Attached.

Attachments

SqueakDebug.log.txt (4.5 kB) - added by bert 6 years ago.
org.vpri.EtoysActivity-7.log (8.7 kB) - added by bert 6 years ago.
instance.tar.gz (15.3 kB) - added by bert 6 years ago.

Change History

Changed 6 years ago by bert

Changed 6 years ago by ohshima

The issue is that the string via clipboard returns null-terminated strings, and Etoys happily takes it as a project name, if it is pasted into the project name field. When the temporary file is created based on the project name, the file name will contain 0 in the middle, and Unix tests the existing of the truncated name.

If the string in a TextMorph contains 0, the editing breaks and further copy and paste breaks. #8203 is essentially the same issue with this one.

Changed 6 years ago by ohshima

  • next_action changed from code to test in build

A workaround has been pushed as 2120zeroClipboardWorkaround-yo.

Changed 6 years ago by cjb

  • keywords blocks-:8.2.0 added; blocks?:8.2.0 removed

Shouldn't block our release.

Changed 6 years ago by bert

Changed 6 years ago by bert

Changed 6 years ago by bert

  • cc marco, tomeu added
  • next_action changed from test in build to diagnose

I did the same in the latest version (8.2-759). The clipboard issue appears to be fixed, but we get back an error from the datastore. Is it possible the DS cannot handle a file name like "तारा.002.pr"? I attached a log, as well as the instance directory which indeed has a file with that name.

To reproduce run Etoys, make new project, switch language to Nepali, get a star from supplies bin, get its halo, copy its name, paste as activity title, quit, resume the entry, quit again.

Changed 6 years ago by ohshima

So, I got a different symptom. I installed 8.2-759 via olpc-update and remove the store directory entirely. Then I tried the above once. There, the project *appeared* to be saved. But in the store directory, I only get the .metadata file but not the content itself. This problem was reported elsewhere.

Last time it happened, I did full-flashing and somehow it solved this "metadata-only" problem. I'll do it later and see if I can reproduce it.

Changed 6 years ago by ohshima

Ah, ok. The filename argument for SugarLauncher>>createJournalEntryFor:filename:mimetype: can be a WideString. Not sure what is best, but asDbusArgument for WideString can have the conversion to UTF-8?

Changed 6 years ago by bert

Almost - dbusCoerceTo: is better for that. I'll make it convert WideString to UTF8.

But for createJournalEntry we should use asVMPathName, shouldn't we?

Changed 6 years ago by bert

  • keywords 8.2.0:+ joyride-2390:- added; blocks-:8.2.0 removed
  • next_action changed from diagnose to package
  • summary changed from Etoys saving fails to Etoys saving fails for non-ascii project names

No, you were right, simple UTF8 encoding is better than asVmPathName.

Pushed 2131dbusCore45-bf and 2132datastoreEnc-bf for this. Works great as far as I can tell.

Changed 6 years ago by bert

  • status changed from new to closed
  • resolution set to fixed

Fixed in 8.2-760.

Note: See TracTickets for help on using tickets.