Opened 12 years ago

Closed 11 years ago

#1199 closed bug (fixed)

Haiku-created files with cyrillic names are not visible from R5 and vice versa.

Reported by: siarzhuk Owned by: bga
Priority: low Milestone: R1
Component: File Systems/BFS Version: R1/pre-alpha1
Keywords: Cc: jonas.kirilla
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

NOTE:Before reproducing this bug, please change your font settings to use DejaVu fonts family. Default Vera family of fonts has no symbols in cyrillic section and results of this test will be not visible. Looks like reboot is also required after fonts reconfiguration.

To show this problem I wrote a simple shell script (attached as CyrDirTest.sh). It create the directory with predefined name, containing cyrillic symbols. This script also create a file with cyrillic name inside of this directory. This script accept the command line parameter that will be used to add prefix to directory name.

Stage I) 0) Boot BeOS R5. Haiku partition should be mounted at /Haiku. 1) make directory /Haiku/home/1 2) copy CyrDirTest.sh to this directory. 3) Open the Terminal and cd to /Haiku/home/1 4) Call CyrDirTest.sh with parameter R5

The screenshot "1.Created under R5.png" show the results. The last window pointed by green arrows is StyledEdit with created file. Note also the Terminal window with information reported by "ls".

Stage II) 0) Reboot to Haiku. 1) Open the ~/1 in Tracker. You should see the cyrillic-named directory created from R5. 2) Open this directory. Note that file is not visible in Tracker. 3) Open Terminal, cd to ~/1 and call "ls -lR". The "ls" command repport that it "cannot access", "no such file or directory" about the file inside of this directory.

The screenshot "2.R5 created, opened under Haiku.png" illustrate this situation. Follow the red arrows to see the problems. Note the way Terminal show non-latin filenames. I think it is not related to our bug - just not finished implementation of utf8 support in Terminal.

Stage III) 0) Assure that you are still in Haiku ~/1 directory. 1) Call CyrDirTest.sh with parameter H1. 2) The cyrillic-named directory with prefix "H1" will be created. The file with cyrillic name is also created and accessible. Note that we have used the same script as from BeOS R5.

The screenshot "3.Created under Haiku.png" illustrate this stage. Follow green arrows for directory created under R5 and blue arrows for directory created under Haiku. And note the difference between those directories in "ls" command output in Terminal (follow the red arrow)

Stage IV) 0) Reboot back to BeOS R5. Haiku should be mount as /Haiku 1) Open both "R5"-prefixed directory and "H1"-prefixed one from the Tracker. The file created from R5 in Stage I of our tests are now accessible, but file created from Haiku at Stage III is not visible.

The screenshot "4.Haiku-created,opened under R5.png" represent us the results of this test. Follow green arrows for directory and file created from BeOS, and follow blue arrows for ones created from Haiku. Note the Terminal window with output of "ls" command - now the Haiku created files are "not found" (follow red arrow).

I suspect some incompatibilities in non-latin names handling in Haiku BFS implementation. It looks like neither Tracker nor Terminal problem.

PS. BTW, if you try to call CyrDirTest.sh with parameter "R5" at Stage III (under Haiku) - script report that "directory already exists". And it is really exists - it was created under R5 at State I of our tests.

Attachments (5)

CyrDirTest.sh (264 bytes) - added by siarzhuk 12 years ago.
The script used to create directory and nested file with cyrillic characters in names.
1.Created under R5.png (26.3 KB) - added by siarzhuk 12 years ago.
SShot with results of creating directory and nested file under BeOS R5
2.R5 created, opened under Haiku.png (66.5 KB) - added by siarzhuk 12 years ago.
Screenshot with directory and file created under BeOS R5 and opened by Haiku
3.Created under Haiku.png (106.8 KB) - added by siarzhuk 12 years ago.
Screenshot with results of script call under Haiku
4.Haiku-created,opened under R5.png (23.2 KB) - added by siarzhuk 12 years ago.
The final screenshot with directory and file, created under Haiku and opened under BeOS R5

Download all attachments as: .zip

Change History (9)

Changed 12 years ago by siarzhuk

Attachment: CyrDirTest.sh added

The script used to create directory and nested file with cyrillic characters in names.

Changed 12 years ago by siarzhuk

Attachment: 1.Created under R5.png added

SShot with results of creating directory and nested file under BeOS R5

Changed 12 years ago by siarzhuk

Screenshot with directory and file created under BeOS R5 and opened by Haiku

Changed 12 years ago by siarzhuk

Attachment: 3.Created under Haiku.png added

Screenshot with results of script call under Haiku

Changed 12 years ago by siarzhuk

The final screenshot with directory and file, created under Haiku and opened under BeOS R5

comment:1 Changed 12 years ago by jonas.kirilla

Cc: jonas.kirilla added

I see this too, with the japanese language files from Wonderbrush. (WonderBrush-1.7.2-x86-R5.zip)

These are in my /Haiku/apps folder as I had copied the full /boot/apps of my BeOS R5/Bone installation. I found this incompatibility when trying to install from Haiku to another partition, using Haiku's Installer, which fails on these two files with UTF8 characters created from BeOS.

comment:2 Changed 11 years ago by siarzhuk

After #724 was fixed I have checked the state of this problem. Looks like hrev24498 works in right way - both cyrillic-named file system entities created in R5 and ones created in Haiku are visible from any system. Looks like the problem is solved.

The question to jonas.kirilla: it is all OK now on your side? Have you any objections to close this ticked as fixed?

comment:3 Changed 11 years ago by jonas.kirilla

I can't check as my Haiku screen is garbled at the moment. Feel free to close though.

comment:4 Changed 11 years ago by stippi

Resolution: fixed
Status: newclosed

From all the feedback so far, I am guessing that this bug is positively fixed.

Note: See TracTickets for help on using tickets.