uc1541 failure

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/2864
Reporter	gryf (gryf_esm@….pl)

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.

Note

Original attachments:

• test.d64 (raw) by gryf (gryf_esm@….pl) on Aug 11, 2012 at 6:01 UTC
• dir_under_vice.png (raw) by gryf (gryf_esm@….pl) on Aug 27, 2012 at 14:06 UTC
• uc1541 (raw) by gryf (gryf_esm@….pl) on Sep 24, 2012 at 19:22 UTC

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Aug 10, 2012 at 5:13 UTC (comment 1)

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

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 11, 2012 at 6:01 UTC

• Attachment test.d64 (raw) added

D64 image file for test purposes

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 11, 2012 at 6:23 UTC (comment 2)

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.

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Aug 12, 2012 at 7:31 UTC (comment 3)

but uc1541 contain "Licence: BSD"...

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 12, 2012 at 14:12 UTC (comment 3.4)

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.

[mc-butler]

Changed by zaytsev (@zyv) on Aug 14, 2012 at 9:14 UTC (comment 5)

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

[mc-butler]

Changed by slavazanko (@slavaz) on Aug 21, 2012 at 7:27 UTC (comment 6)

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

[mc-butler]

Changed by slavazanko (@slavaz) on Aug 22, 2012 at 7:34 UTC (comment 7)

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

Created branch 2864_uc1541 [c01da01975b4f388162ac5c9200dde9d13d9cd92].
Review, please.

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 22, 2012 at 8:57 UTC (comment 8)

• Votes set to andrew_b

[mc-butler]

Changed by angel_il (@ilia-maslakov) on Aug 27, 2012 at 6:30 UTC (comment 9)

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   

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 27, 2012 at 6:37 UTC (comment 10)

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?

[mc-butler]

Changed by andrew_b (@aborodin) on Aug 27, 2012 at 6:40 UTC (comment 9.11)

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.

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 27, 2012 at 13:29 UTC (comment 11.12)

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 :/

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 27, 2012 at 14:06 UTC (comment 10.13)

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 filename which c1541 outputs, or there is some character, which c1541 cannot map to ASCII, 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?

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Aug 27, 2012 at 14:06 UTC

• Attachment dir_under_vice.png (raw) added

directory listing under vice emulator

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Sep 2, 2012 at 18:12 UTC (comment 14)

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.

[mc-butler]

Changed by slavazanko (@slavaz) on Sep 5, 2012 at 11:25 UTC (comment 15)

uc1541 file have updated in branch

review again, please.

[mc-butler]

Changed by slavazanko (@slavaz) on Sep 5, 2012 at 11:29 UTC (comment 16)

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

[mc-butler]

Changed by slavazanko (@slavaz) on Sep 5, 2012 at 11:33 UTC (comment 17)

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

Merged to master:

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

[mc-butler]

Changed by slavazanko (@slavaz) on Sep 5, 2012 at 11:33 UTC (comment 18)

• Status changed from testing to closed

[mc-butler]

Changed by slavazanko (@slavaz) on Sep 5, 2012 at 11:59 UTC (comment 19)

Cherry-picked to stable:

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

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Sep 24, 2012 at 19:22 UTC

• Attachment uc1541 (raw) added

proposed uc1541 replacement

[mc-butler]

Changed by gryf (gryf_esm@….pl) on Sep 24, 2012 at 19:25 UTC (comment 20)

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