coreutils updated port?

Is anyone maintaining the coreutils port?

I take it that programs like "mkdir" and "cp" are part of the coreutils?

I found a reproducable case of an mkdir bug.
I *think* it might have to do with permission setting of that unix command.

If i let ScummVM automatically install the binary and extra stuff (with mkdir) nothing can be accessed from those directories after i start ScummVM.

e.g.

mkdir -p ScummVM:themes
cp allthemestuff to ScummVM:themes

If i now start ScummVM which points to the aforementioned themes dir, it will warn me about missing theme data and load the fallback (inbuilt) classic theme instead.

If i do the exact same with AmigaOS`makedir, it works fine.

WBInfo shows all of the needed permissions (rwed) given, but it seems they are not.

Easy test case is, to create the dirs with mkdir, copy the stuff in and start ScummVM.


Not sure to whom i should point this bug report, anyone know?

btw: i tested chmod on that dirs with no change, also tested mkdir's -mode switch with no errors, but also no change in the outcome.


Another error i get with "cp" and .zip archives (they turn up corrupted every time)

CBB with the dir thing, but for cp:
I have three bit different cp, all of them copied the same 190 kB PKzip file from ext2|3 volume to RAM disk. unzip -t had "No errors detected" to say for all.

For what ever it's worth, cp md5sums:
17a52d1cc8b70a65d9b868113e1a5937
e49d4ed579191cce1ac0c6bb158a7ed1
1e78027e5d6654043102166c34d0018e

@Thematic

lol, mine has
dc3bf457664d4f8ee99a765b95c42441 SDK:gcc/bin/cp

and i was maybe exaggerating a bit, they don't turn up corrupted every time, but often enough to make me write a script that checks and recopyies them if they differ...go figure

@Raziel

doing a "protect +rwed" over those dirs doesn't help either, they are fundamentally broken.

I have changed the automatic installation in ScummVM's build process to using "Makedir" instead now.

how about the amicygnix one?

@NinjaCyborg

I don't have that installed and i'd rather not mix stuff into the SDK.
Makes keeping track of updates impossible

APPDIR: even is in path by default now... so that's something to consider changing. That must be why I see double.

@Thematic

I'm sorry, can't follow you there

an on a different note, your avatar is broken

@Raziel

Those are a part of coreutils, not binutils, which is a good thing. There are two different versions in adtools, 5.2 and 8.27. 8.27 isn't ancient so someone must have done some work on it. That being said, that bug is not a part of coreutils (there's no way something like that can slip through upstream), so unless the Amiga specific patches have been fixed in 8.27 (and not backported) updating won't help. Maybe the problem is in newlib / clib2, but I guess that's less likely since then it should have shown up in many many places I guess.

@Raziel

Try adding the option "--sparse=never" to the cp command.

If it helps then the file corruption is likely due to a long standing bug in newlib.library that was fixed in V53.59 (AmigaOS 4.1 FE update 2 has V53.61 so it shouldn't have this problem).

You can find the latest coreutils at:
http://os4depot.net/share/development/utility/coreutils.lha

@Raziel

There's a Path ADD APPDIR:
in startup-sequence

and if I do "which cp all" I get the same cp full path twice, since APPDIR: will be automatically expanded (that's how I figure it).

Avatar isn't broken, it's something in Odyssey. Multiview and anything else deal with it.

@Thematic

I see, seems pretty messy.

@salass00

So, i take it that the coreutils are the way to go?

Since the cp command from within this coreutils package is the same version (8.27) as the one in sdk:local/c i wonder which one to use.

Also, why are the gcc builds packaged with outdated versions of those tools and how can i learn my SDK to not use them?


Preferably by not deleting the outdated ones, who knows which can of worms is opened then...

Hmm, maybe by simply using the all-in-one coreutils?

coreutils --coreutils-prog=cp from-file to-file

Looks and feels ... uneasy

So, it seems mkdir from coreutils has a bug as well

coreutils --coreutils-prog=mkdir -p ram:test/test1

mkdir: cannot create directory 'ram:test/test1': No such file or directory


The same goes for a simple one level directory

coreutils --coreutils-prog=mkdir -p ram:test

No error message, but also no directory created


Unless i'm doing domething wrong (i tried hdd and ram), it seems coreutils mkdir is broken (at least the parent switch is), leaving that out creates a single directory, not usable on 2 or more level subdirs, though)

LOL

So, 8.27 coreutils mkdir suffers from the same problem.
Created directories are not accessible from within ScummVM...back to makedir


Who would i point my bugreports to then?

@Raziel

I tried to build from ram: as well. I noticed path errors in the log that started with /disk/.
Turns out that binutils has a problem with ram: because it is an assign to "Ram Disk"
So it cannot cope with spaces in paths.
Moved the project to work: and everything compiled as expected.
Maybe this explains your mkdir issue.

@geennaam

Nope.

My problem is as simple as

'mkdir -p work:test' (which will *not* create a directory with 8.27, but with 5.2.1)
'mkdir -p work:test/test1' (which will *not* create a directory with 8.27, but with 5.2.1)

'mkdir work:test' (which *will* create a directory with both 8.27 and 5.2.1)
'mkdir work:test/test1' (which will *not* [obviously] create a directory with both 8.27 and 5.2.1)

Both 5.2.1 and 8.27 create directories which can *not* be accessed from within the running SDL app ScummVM (if that is a problem with the app's file/dir i/o code in ScummVM or the way mkdir creates - and probably messes up - directories, i cannot really say, but ScummVM's i/o code was reviewed multiple times and no one found any issues -or at least told me about it -, so i'm still pointing my finger at mkdir.

@Raziel

Quote:

As coreutils is from posix you should not expect it to work well with AmigaDOS style paths.

Instead you should use unix style paths, like so:
mkdir -p /work/test/test1

@salass00

Err...true... :-/

Still, the produced but not working directories are an issue.

@Raziel

Quote:

You're not really supposed to use it like that.

Coreutils, like some other unix programs I've come across, implements all functionality in one executable that then acts differently depending on what name it is called by from the CLI (argv[0]).

So for instance if you make a copy of the coreutils program or a soft link to it called "mkdir" then it will act when run as if it is the mkdir command, and if you call it "cp" it will act as the cp command.

If you install the coreutils archive from OS4Depot using AmiUpdate or by manually executing the AutoInstall script from a CLI then it creates the soft links for you automatically.

@Raziel

Well, it does not make sense that you like to use Amiga paths in makefiles or sh scripts.

And it does not make sense to use absolute paths like that, if your working on project. not everyone will put files in same place. It’s better to use relative paths, like parent directory.

When writing amiga scripts you should not use gnu commands, but stick to Amiga commands MakeDir. (not everyone has sdk installed.)

having said that, I can understand that amiga path can easily end up in sh script, and of course it would have been nice if both Linux and Amiga paths worked, without thinking about it.