I know you have said here that we are not allowed to distribute the receiver.arf file. This makes it relatively difficult for Windows users to take advantage of patched kernels for the Receiver.

Because of this I have only released the zImage file for my patched kernel and not the matching receiver.arf file.

Would it be acceptable for me to provide a service via a web page where Windows users could upload their copy of receiver.arf, have my web page generate an MD5 checksum on the uploaded file and allow them to download a patched version of receiver.arf if their file's checksum matches the receiver.arf that ships with the receiver ?

That way I would not be distributing receiver.arf, just providing a patching service for people...

...have my web page generate an MD5 checksum on the uploaded file and allow them to download a patched version...

Heh, this sounds suspiciously like the "my MP3.com" thing that got nailed so hard a while back. Anyone remeber that one?

Yeah, I realise that it is a grey area...

I was orginially going to propose a service that actually patched the arf file, i.e. they uploaded their file, it patched it and they downloaded it again. But that seemed a bit silly when just checking the file is the same and letting them download the patched version amounts to the same thing.

Hey andy, good to know that someone is hacking this Receiver - its well overdue for some serious updating.

regarding patching the Receiver.arf file, why not create a Windows utility that lets people drag and drop new files into the Receiver.arf file and have the utility create a new arf file with the new and/or updated files in it?

I can program in VB and could knock up such a program in a weekend - yes it would be something you'd distribute/let folks download and install themselves, but iot could keep backup copies of the .arf files before it updated them so you could go back.

I think arf files are basically compressed tar files? or similar?

In any case, It would be good to work with you as I'm getting my rio receiver this week and its something I'll be hacking with before too long so we may be able to pool our resources - I'm not a kernel hacker or anything like that although I can program in C and Unix and have been doing that for years, I don't run Linux at home either - but I have 2 hacked Tivos & 4 empegs - does that count?

It's extremely unlikely that we'll allow you to distribute any kind of .arf file. However, it is just a simple TAR file -- it's not even gzipp'ed. Writing something to update the kernel inside the TAR file should not be too difficult.

Unfortunately, you can't use Winzip -- it shafts device files.

regarding patching the Receiver.arf file, why not create a Windows utility that lets people drag and drop new files into the Receiver.arf file and have the utility create a new arf file with the new and/or updated files in it?

That would be good, but I don't have time to write such an app at the moment.

I can program in VB and could knock up such a program in a weekend - yes it would be something you'd distribute/let folks download and install themselves, but iot could keep backup copies of the .arf files before it updated them so you could go back.

That would be great if you or someone could write it.

I think arf files are basically compressed tar files? or similar?

They are not compressed, they are just plain tar files.

I'd send you an arf file to work on until you get your Receiver, but I'm not allowed to...

While I realise SB is perfectly within it's rights to take this stand, I don't understand the point of it. I also understand that there is unlikely to be any movement on this.

I would understand if I was attempting to distribute a patched copy of the player executable or the PNA module, but apart from the patched GPL'd kernel the arf file is unchanged. I don't see why SB choose to not allow this.

Can someone please explain it to me ?

Also, if I created a service whereby users could upload their arf to be patched then the arf wouldn't be being distributed would it (as I wouldn't be giving them my arf, just patching theirs for them)? After all this is functionally no different to giving them a VB app to do it themselves.

All this, because it is going to be far easier for me to create a page on my Linux box to accept the arf and use tar to patch it than to write a VB app to handle tar files...

Does WinRAR jack up device files too? It usually seems to be more Linux friendly. I was just curious if anyone had any experience with it.

Thanks.

John

It looks like the answer is yes I'm afraid. You add files to a tar file using WinRAR you have to extract the whole thing and delete the old zImage, add the new one and tar it back up. So it has the same problem as WinZip.

Well, for better or for worse I have embarked on writing my own tar archive handling app in VB. Wish me luck...

P.S. I really wish I didn't have to do this.

P.S. I really wish I didn't have to do this.
------------------------------------------------------------------
Not to clear what "this" is. Thaere are already Windoze compliant tar tools around (GNU). I _think_ the real problem is the Windoze filesystems don't support all the file attributes that a UNIX filesystem does (owner, group, mode, links etc.).

Sounds like you need to
Collect the file attribute information (tar -tvf) into an additional file. Then use GNU tar to untar the arf file. Make your changes, then use GNU tar again to rebuild the arf file.
As the attributes of the files have now been lost you need to recreate them directly.
So you need to write a tool which will parse the info file you built in the first step and directly update the attributes stored in the arf file.
I would suggest skip VB, do it in C. Then you can make use of the GNU source code dirctly. License permitting of course.

Dobbs

In reply to:

---

I';d send you a Receiver.arf file but I'm not allowed to...

---

I got one already, courtesy of the Dell Web site.
[just say you have a Dell audio Receiver and it dishes up the latest rio Receiver software - good enough to get started - even if you don;t have a Dell Audio Receiver].

Can't understand why SB aren't doing the same on their website.

doesn't regular tar have a 'update' option in it which allows you to update files in the archive with newer ones?

[I know the man page warned that that was slow, but it would be a simple hack to simply call gnutar with the right arguments to simply update a single file than repackage the whole enchilada].

Heres the help output from the cygwin tar program:

GNU `tar' saves many files together into a single tape or disk archive, and
can restore individual files from the archive.

Usage: tar [OPTION]... [FILE]...

If a long option shows an argument as mandatory, then it is mandatory
for the equivalent short option also. Similarly for optional arguments.

Main operation mode:
-t, --list list the contents of an archive
-x, --extract, --get extract files from an archive
-c, --create create a new archive
-d, --diff, --compare find differences between archive and file system
-r, --append append files to the end of an archive
-u, --update only append files newer than copy in archive
-A, --catenate append tar files to an archive
--concatenate same as -A
--delete delete from the archive (not on mag tapes!)

Operation modifiers:
-W, --verify attempt to verify the archive after writing it
--remove-files remove files after adding them to the archive
-k, --keep-old-files don't overwrite existing files when extracting
-U, --unlink-first remove each file prior to extracting over it
--recursive-unlink empty hierarchies prior to extracting directory
-S, --sparse handle sparse files efficiently
-O, --to-stdout extract files to standard output
-G, --incremental handle old GNU-format incremental backup
-g, --listed-incremental handle new GNU-format incremental backup
--ignore-failed-read do not exit with nonzero on unreadable files

Handling of file attributes:
--owner=NAME force NAME as owner for added files
--group=NAME force NAME as group for added files
--mode=CHANGES force (symbolic) mode CHANGES for added files
--atime-preserve don't change access times on dumped files
-m, --modification-time don't extract file modified time
--same-owner try extracting files with the same ownership
--numeric-owner always use numbers for user/group names
-p, --same-permissions extract all protection information
--preserve-permissions same as -p
-s, --same-order sort names to extract to match archive
--preserve-order same as -s
--preserve same as both -p and -s

Device selection and switching:
-f, --file=ARCHIVE use archive file or device ARCHIVE
--force-local archive file is local even if has a colon
--rsh-command=COMMAND use remote COMMAND instead of rsh
-[0-7][lmh] specify drive and density
-M, --multi-volume create/list/extract multi-volume archive
-L, --tape-length=NUM change tape after writing NUM x 1024 bytes
-F, --info-script=FILE run script at end of each tape (implies -M)
--new-volume-script=FILE same as -F FILE
--volno-file=FILE use/update the volume number in FILE

Device blocking:
-b, --blocking-factor=BLOCKS BLOCKS x 512 bytes per record
--record-size=SIZE SIZE bytes per record, multiple of 512
-i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
-B, --read-full-records reblock as we read (for 4.2BSD pipes)

Archive format selection:
-V, --label=NAME create archive with volume name NAME
PATTERN at list/extract time, a globbing PATTERN
-o, --old-archive, --portability write a V7 format archive
--posix write a POSIX conformant archive
-y, --bzip2, --bunzip2 filter the archive through bzip2
-z, --gzip, --ungzip filter the archive through gzip
-Z, --compress, --uncompress filter the archive through compress
--use-compress-program=PROG filter through PROG (must accept -d)

Local file selection:
-C, --directory=DIR change to directory DIR
-T, --files-from=NAME get names to extract or create from file NAME
--null -T reads null-terminated names, disable -C
--exclude=PATTERN exclude files, given as a globbing PATTERN
-X, --exclude-from=FILE exclude globbing patterns listed in FILE
-P, --absolute-names don't strip leading `/'s from file names
-h, --dereference dump instead the files symlinks point to
--no-recursion avoid descending automatically in directories
-l, --one-file-system stay in local file system when creating archive
-K, --starting-file=NAME begin at file NAME in the archive
-N, --newer=DATE only store files newer than DATE
--newer-mtime compare date and time when data changed only
--after-date=DATE same as -N
--backup[=CONTROL] backup before removal, choose version control
--suffix=SUFFIX backup before removel, override usual suffix

Informative output:
--help print this help, then exit
--version print tar program version number, then exit
-v, --verbose verbosely list files processed
--checkpoint print directory names while reading the archive
--totals print total bytes written while creating archive
-R, --block-number show block number within archive with each message
-w, --interactive ask for confirmation for every action
--confirmation same as -w

The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control may be set with --backup or VERSION_CONTROL, values are:

t, numbered make numbered backups
nil, existing numbered if numbered backups exist, simple otherwise
never, simple always make simple backups

GNU tar cannot read nor produce `--posix' archives. If POSIXLY_CORRECT
is set in the environment, GNU extensions are disallowed with `--posix'.
Support for POSIX is only partially implemented, don't count on it yet.
ARCHIVE may be FILE, HOST:FILE or USER@HOST:FILE; and FILE may be a file
or a device. *This* `tar' defaults to `-f- -b20'.



This means that you can specify all kinds of stuff like owner,group and mode of added files - so that removes that as a problem.

The only issue I see it is the .arf file extracted to a ram disk, and if so, then later files in .arf file will simply overwrite earlier ones right?
then thats a no-brainer too - simply update or append your new kernel to the .arf file via cygwin tar and let it rip - yes the arf files grows, but who cares, for now its a simple fix.

You are missing my point, if people had the tar utility on their Windows boxes then the issue over the Windows filesystems not supporting the extra features is a moot point. This is because the GNU tar util can update tar files in place, thus solving that particular problem.

The problem that my tool is going to address is the fact that most Windows users do not have a copy of tar on their machines. GNU tar is available from http://www.cygwin.com/, but only as part of their Unix tools suite, which means a 20Mb+ download, just to get one utlility that you they are unlikely to use for any other purpose.

I suspect that the average Receiver user is going to be less keen to "get their hands dirty" than the average empeg user, I don't think many of them are going to install http://www.cygwin.com/ just to try out new software for their Receiver. It is also clear that most Receiver users don't read this BBS (only 150 registered users), so I'm not quite sure how they are going to find out about the patch, but that's a different problem...

Believe me, it is far easier for me to write the tool in VB. I'm afraid VB is my natural enviroment, it would take someone far more on the ball with C to make the GNU tar source work on Windows.

Anyway, it turns out that the tar file format is more simple that you would imagine, so the tool is nearly finished.

doesn't regular tar have a 'update' option in it which allows you to update files in the archive with newer ones?

Yes it does.

This means that you can specify all kinds of stuff like owner,group and mode of added files - so that removes that as a problem.

The only issue I see it is the .arf file extracted to a ram disk, and if so, then later files in .arf file will simply overwrite earlier ones right?
then thats a no-brainer too - simply update or append your new kernel to the .arf file via cygwin tar and let it rip - yes the arf files grows, but who cares, for now its a simple fix.

We already know that this all works, I included details of how to do it on my web page. You don't in fact need to end up with a substantially bigger ARF file because you can also delete the old zImage file from the ARF file.

However, all of this pre supposes that the Receiver user is willing to download and use the cygwin software. Some of them will do that, some of them will not want to.

My tool (which should hopefully be finished later today) is for those who are unwilling to download and use the cygwin tools.

I'll look forward to being able to play with this software soon then.

I think bundling in the cygwin tar plus support DLLs should also be allowable as an 'alternative' method of being able to update the arf files.

My new Receiver Tweaker tool (imaginative name, no ?) is now available from http://www.norman.cx/receiver/receiver-tweaker.asp

Has anyone tried the msdos gnutar available straight from gnu.org? (for example, here: ftp://ftp.uu.net/archive/systems/gnu/tar/)

I downloaded the tar-1.12.msdos.exe, copied it to \winnt\tar.exe, and was able to (apparently) delete a file and replace it with something else, all while (again, apparently) retaining the proper node numbers in /dev. (I don't actually have a receiver.arf file with me at work, I just created a test file with some simple nodes on a unix box).

Anyone tried it? Can anyone verify that it works? (since all my units are served by a linux server, I'm sort of skipping over the whole .arf thing entirely... )


-david.

It should work fine and is certainly a much smaller download than the cygwin suite.