-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uc1541 failure #2864
Comments
can you attache the uc1541 image for tests? (~100-200KB) |
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. |
but uc1541 contain "Licence: BSD"... |
Replying to angel_il:
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. |
Iliya: re-using New BSD/MIT code is not a problem as these licenses are compatible with GPLv3. |
|
Created branch 2864_uc1541 [c01da01975b4f388162ac5c9200dde9d13d9cd92]. |
|
|
The deeper testing shows some unexpected behavior of new uc1541 plug-in:
Are these bugs or features? |
Replying to angel_il:
Incompatibility with python-2.7? With python-2.5, everything is ok. |
Replying to andrew_b:
Whoa. It was developed and tested against python 2.7 :/ |
Replying to andrew_b:
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.
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:
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.
Neither of those. This is limitation of c1541.
But what bugs me most is how were you got such a traceback? Is it reproducible? |
directory listing under vice emulator |
I've just uploaded new version of the script, which fixes following issues:
It was quite a fun to develop this. Hope you like it. |
uc1541 file have updated in branch
review again, please. |
|
Merged to master:
|
|
Cherry-picked to stable:
|
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 |
Important
This issue was migrated from Trac:
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:
gryf
(gryf_esm@….pl) onAug 11, 2012 at 6:01 UTC
gryf
(gryf_esm@….pl) onAug 27, 2012 at 14:06 UTC
gryf
(gryf_esm@….pl) onSep 24, 2012 at 19:22 UTC
The text was updated successfully, but these errors were encountered: