Ticket #2864 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

uc1541 failure

Reported by: gryf Owned by: slavazanko
Priority: minor Milestone: 4.8.5
Component: mc-vfs Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

Due to date formatting, uc1541 extfs plugin is unusable, even tough the date formatting, which is the one cause of the problem is coherent with the attached documentation (MM-DD-YYYY hh:mm). This is probably bug in MC.

Another problem with uc1541 script is connected rather with legal characters used in filename rather than with script itself - in PET ASCII it is perfectly fine to use slash "/" character in filenames, and as a side effect all files containing slash inside d64 image are represented as directories on MC. This issue in my opinion has to be worked out in the script itself.

I've rewritten shell script in python which fixes problems described above.

Attachments

test.d64 (170.8 KB) - added by gryf 12 years ago.
D64 image file for test purposes
dir_under_vice.png (4.4 KB) - added by gryf 12 years ago.
directory listing under vice emulator
uc1541 (18.2 KB) - added by gryf 12 years ago.
proposed uc1541 replacement

Change History

comment:1 Changed 12 years ago by angel_il

can you attache the uc1541 image for tests? (~100-200KB)

Changed 12 years ago by gryf

D64 image file for test purposes

comment:2 Changed 12 years ago by gryf

There an issue with files that begins with spaces - extfs mechanism strips them, so that it is impossible to access such a file from the generated view.

Due to c1541 implementation, only 'prg' files are accessible. Sometimes it is necessary to add jokers to the filename to access it (for example koala pictures, which contains control character at the beginning of their filenames), and that is possible only manually.

Last edited 12 years ago by gryf (previous) (diff)

comment:3 follow-up: ↓ 4 Changed 12 years ago by angel_il

but uc1541 contain "Licence: BSD"...

comment:4 in reply to: ↑ 3 Changed 12 years ago by gryf

Replying to angel_il:

but uc1541 contain "Licence: BSD"...

Yes, I thought that BSD/MIT/Apache is liberal enough to be used with any software (including that on GPL licenses). I that a problem? If so, I'll change it to whatever it should be.

comment:5 Changed 12 years ago by zaytsev

Iliya: re-using New BSD/MIT code is not a problem as these licenses are compatible with GPLv3.

comment:6 Changed 12 years ago by slavazanko

  • Owner set to slavazanko
  • Status changed from new to accepted

comment:7 Changed 12 years ago by slavazanko

  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.5

Created branch 2864_uc1541.
Review, please.

comment:8 Changed 12 years ago by andrew_b

  • Votes for changeset set to andrew_b

comment:9 follow-up: ↓ 11 Changed 12 years ago by angel_il

Traceback (most recent call last):                                              
  File "/home/holmes/.local/share/mc/extfs.d/uc1541", line 238, in <module>     
    parse_func()                                                                
  File "/home/holmes/.local/share/mc/extfs.d/uc1541", line 198, in parse_args   
    return args.func(args)                                                      
  File "/home/holmes/.local/share/mc/extfs.d/uc1541", line 158, in <lambda>     
    CALL_MAP = {'list': lambda a: Uc1541(a.ARCH).list(),                        
  File "/home/holmes/.local/share/mc/extfs.d/uc1541", line 49, in list          
    if not self._call_command('list'):                                          
  File "/home/holmes/.local/share/mc/extfs.d/uc1541", line 154, in _call_command
    stderr=PIPE).communicate()                                                  
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__                
    errread, errwrite)                                                          
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child         
    raise child_exception   

comment:10 follow-up: ↓ 13 Changed 12 years ago by andrew_b

The deeper testing shows some unexpected behavior of new uc1541 plug-in:

  • plugin doesn't allow to view zero-length files (f3/f4 on that files does nothing)
  • f3/f4 on .pic koala .prg file also does nothing. File has 10240 bytes length. Maybe, leading dot is reason.

Are these bugs or features?

comment:11 in reply to: ↑ 9 ; follow-up: ↓ 12 Changed 12 years ago by andrew_b

Replying to angel_il:

  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child         
    raise child_exception   

Incompatibility with python-2.7? With python-2.5, everything is ok.

comment:12 in reply to: ↑ 11 Changed 12 years ago by gryf

Replying to andrew_b:

  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child         
    raise child_exception   

Incompatibility with python-2.7? With python-2.5, everything is ok.

Whoa. It was developed and tested against python 2.7 :/

comment:13 in reply to: ↑ 10 Changed 12 years ago by gryf

Replying to andrew_b:

The deeper testing shows some unexpected behavior of new uc1541 plug-in:

  • plugin doesn't allow to view zero-length files (f3/f4 on that files does nothing)

All "del" files are treated as no-read files with witch permissions: ----------, they cannot be read by c1541 either.

Also, please bear in mind that sometimes it'll be impossible to read a file from d64 image, because disc can be treated as a storage place and tracks can be accessed by some c64 program directly, without participation of Commodore disc operating system. In such a case there could be dummy entries on track 18, where directory is stored.

  • f3/f4 on .pic koala .prg file also does nothing. File has 10240 bytes length. Maybe, leading dot is reason.

Leading dot means, that either there is a dot ($2E) at the beginning of c1541 program, or there is some character, which c1541 cannot map to ASCI, so basically it means that there is some PET-ASCII specific character (for example $AD, $C0 etc) or some control character (in this case: $81 - control character for orange color). Currently there is no other way to access such a file than using jokers, for this paricular file, invocation for reading it via c1541 would be:

$ c1541 -attach test.d64 -read "?pic koala     " picture.kol

Same goes for other files. Here goes the screenshot how entries should look.

Another story are files with leading space - there is no way to transfer them, even thought there is no problem with that on command line and c1541. However, this is not specific for UC1541 plugin, but all plugins, since there is no way to quote filenames. I've checked that behaviour with zip archive containing such a file, and wasn't able to read it from MC.

Are these bugs or features?

Neither of those. This is limitation of c1541.

But what bugs me most is how were you got such a traceback? Is it reproducible?

Version 0, edited 12 years ago by gryf (next)

Changed 12 years ago by gryf

directory listing under vice emulator

comment:14 Changed 12 years ago by gryf

I've just uploaded new version of the script, which fixes following issues:

  • F3/F4 on 'del' and 0-length files works, however it is impossible to change 'del' files (cached content can be confusing)
  • Koala files and other with non-ASCII characters are supported (implemented directory reading routine in pure python - for now only D64 format is supported)
  • Added workaround for filenames with space at the beginning (however, as it was stressed before, it is more generic issue than this script. Maybe it is good idea to use pcre instead of iterating and splitting?)
  • minor bugfixes and code cleanup

It was quite a fun to develop this. Hope you like it.

comment:15 Changed 12 years ago by slavazanko

uc1541 file have updated in branch

review again, please.

comment:16 Changed 12 years ago by slavazanko

  • Votes for changeset changed from andrew_b to andrew_b slavazanko
  • Branch state changed from on review to approved

comment:17 Changed 12 years ago by slavazanko

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b slavazanko to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

Merged to master:

git log --pretty=oneline e6963fc..198a10c

comment:18 Changed 12 years ago by slavazanko

  • Status changed from testing to closed

comment:19 Changed 12 years ago by slavazanko

Cherry-picked to stable:

git log --pretty=oneline 12e8f5f...0ec92fd

Changed 12 years ago by gryf

proposed uc1541 replacement

comment:20 Changed 12 years ago by gryf

Where can I upload newer version of the script? For now, i've jus created repository on bitbucket to track changes: https://bitbucket.org/gryf/uc1541

Note: See TracTickets for help on using tickets.