uc1541 failure

[gryf]

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.

[angel_il]

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

[gryf]

D64 image file for test purposes

[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.

[angel_il]

but uc1541 contain "Licence: BSD"...

[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.

[zaytsev]

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

[slavazanko]

Created branch 2864_uc1541.
Review, please.

[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   

[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?

[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.

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

[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 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?

[gryf]

directory listing under vice emulator

[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.

[slavazanko]

uc1541 file have updated in branch

review again, please.

[slavazanko]

Merged to master:

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

[slavazanko]

Cherry-picked to stable:

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

[gryf]

proposed uc1541 replacement

[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