Opened 6 years ago

Closed 6 years ago

#8212 closed defect (fixed)

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
Blocked By: Blocking:
Deployments affected: Action Needed: package
Verified: no

Description

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

Attachments (3)

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.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by bert

comment:1 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.

comment:2 Changed 6 years ago by ohshima

  • Action Needed changed from code to test in build

A workaround has been pushed as 2120zeroClipboardWorkaround-yo.

comment:3 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

comment:4 Changed 6 years ago by bert

  • Action Needed changed from test in build to diagnose
  • Cc marco tomeu added

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.

comment:5 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.

comment:6 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?

comment:7 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?

comment:8 Changed 6 years ago by bert

  • Action Needed changed from diagnose to package
  • Keywords 8.2.0:+ joyride-2390:- added; blocks-:8.2.0 removed
  • 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.

comment:9 Changed 6 years ago by bert

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in 8.2-760.

Note: See TracTickets for help on using tickets.