Re: earmark on hfsplus port

2010-03-23 Thread Ted Roby
On Mon, Mar 22, 2010 at 11:03 PM, Ron McDowell  wrote:

> Everybody here is so friendly!
>
> I know how to use tar, patrick. Having a tarball on that drive that I then
> have to untar to the local [ffs|hfs] seems kind of redundant, inelegant and
> just plain crufty.
>
> --
> Ron McDowell
> San Antonio TX
>
>

SUN and SGI systems have been far worse. I have had to use tar in the past
just to
move data between drives mounted on the same system. This was due to
differing
block sizes.

forget "cp -r " my only choice was:
tar cf - oldstuff/* | (cd /newstuff/; tar xf -;)

tar IS your best friend until you have to preserve resource forks...



Re: earmark on hfsplus port

2010-03-22 Thread patrick keshishian
On Mon, Mar 22, 2010 at 10:03 PM, Ron McDowell  wrote:
> patrick keshishian wrote:
>>
>> On Mon, Mar 22, 2010 at 9:14 PM, Ron McDowell  wrote:
>>
>>>
>>> A note of caution.  I copied a bunch of stuff from an OSX 10.6 partition
>>> to
>>> a FAT32 USB drive, and when looking at that FAT32 USB drive mounted on an
>>> OpenBSD 4.7 system, any filenames that fit into the old DOS
>>> 8-character-dot-3-character naming convention got mapped to all
>>> uppercase.
>>>  Played hell with some of my source trees. :(
>>>
>>
>> learn to use tar(1).
>>
>> --patrick
>>
>>
>
> Everybody here is so friendly!
>
> I know how to use tar, patrick. Having a tarball on that drive that I then
> have to untar to the local [ffs|hfs] seems kind of redundant, inelegant and
> just plain crufty.

but copying files to a limiting fs such as FAT32 is what, elegant?

You are obviously using the usb stick/drive as a transport medium. The
form in which you transfer data in that medium should be one that
preserves the integrity of said data best possible. tar(1) will
provide that integrity.

--patrick



Re: earmark on hfsplus port

2010-03-22 Thread Rod Whitworth
On Mon, 22 Mar 2010 23:14:19 -0500, Ron McDowell wrote:

>Ted Roby wrote:
>> On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:
>>
>>   
>>> I suspect the OP would like to dual boot his intel mac machine and
>>> still have access from OpenBSD to the files stored on a hfsplus
>>> partition.
>>>
>>>-Otto
>>>
>>> 
>>
>>
>> This is more in line with what I am seeking.
>> I have a large amount of data which must be moved over from
>> hfsplus to ffs. Since I am running -current, and seeking to assist
>> with development, -my- solution was to invest in another large
>> SATA drive, and attach via USB. I will format it with FAT32, copy
>> all desired media from large hfsplus backup volume, boot to openbsd,
>> copy all that data to internal FFS, reformat new drive FFS and use as
>> backups.
>>
>> My desire, however, is to possibly give OpenBSD portable hfsplus
>> access on i386 for future Mac migrators.
>>   
>
>A note of caution.  I copied a bunch of stuff from an OSX 10.6 partition 
>to a FAT32 USB drive, and when looking at that FAT32 USB drive mounted 
>on an OpenBSD 4.7 system, any filenames that fit into the old DOS 
>8-character-dot-3-character naming convention got mapped to all 
>uppercase.  Played hell with some of my source trees. :(
>
>I'm not sure if that happened on the OSX write to the FAT32 drive or on 
>the OpenBSD read from the drive... but it's not going to do what I want.

mount that stick on OpenBSD using "mount_msdos -l  
" and I'd bet you have no more problems.


>
>So yes, Ted, I'd like very much to be able to mount an intel Snow 
>Leopard hfs+ file system on OpenBSD.

 Maybe you won't need it now ;-)

R/

*** NOTE *** Please DO NOT CC me. I  subscribed to the list.
Mail to the sender address that does not originate at the list server is 
tarpitted. The reply-to: address is provided for those who feel compelled to 
reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.



Re: earmark on hfsplus port

2010-03-22 Thread Ron McDowell

patrick keshishian wrote:

On Mon, Mar 22, 2010 at 9:14 PM, Ron McDowell  wrote:
  

A note of caution.  I copied a bunch of stuff from an OSX 10.6 partition to
a FAT32 USB drive, and when looking at that FAT32 USB drive mounted on an
OpenBSD 4.7 system, any filenames that fit into the old DOS
8-character-dot-3-character naming convention got mapped to all uppercase.
 Played hell with some of my source trees. :(



learn to use tar(1).

--patrick

  

Everybody here is so friendly!

I know how to use tar, patrick. Having a tarball on that drive that I 
then have to untar to the local [ffs|hfs] seems kind of redundant, 
inelegant and just plain crufty.


--
Ron McDowell
San Antonio TX



Re: earmark on hfsplus port

2010-03-22 Thread patrick keshishian
On Mon, Mar 22, 2010 at 9:14 PM, Ron McDowell  wrote:
> Ted Roby wrote:
>>
>> On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:
>>
>>
>>>
>>> I suspect the OP would like to dual boot his intel mac machine and
>>> still have access from OpenBSD to the files stored on a hfsplus
>>> partition.
>>>
>>>   -Otto
>>>
>>>
>>
>>
>> This is more in line with what I am seeking.
>> I have a large amount of data which must be moved over from
>> hfsplus to ffs. Since I am running -current, and seeking to assist
>> with development, -my- solution was to invest in another large
>> SATA drive, and attach via USB. I will format it with FAT32, copy
>> all desired media from large hfsplus backup volume, boot to openbsd,
>> copy all that data to internal FFS, reformat new drive FFS and use as
>> backups.
>>
>> My desire, however, is to possibly give OpenBSD portable hfsplus
>> access on i386 for future Mac migrators.
>>
>
> A note of caution.  I copied a bunch of stuff from an OSX 10.6 partition to
> a FAT32 USB drive, and when looking at that FAT32 USB drive mounted on an
> OpenBSD 4.7 system, any filenames that fit into the old DOS
> 8-character-dot-3-character naming convention got mapped to all uppercase.
>  Played hell with some of my source trees. :(

learn to use tar(1).

--patrick


> I'm not sure if that happened on the OSX write to the FAT32 drive or on the
> OpenBSD read from the drive... but it's not going to do what I want.
>
> So yes, Ted, I'd like very much to be able to mount an intel Snow Leopard
> hfs+ file system on OpenBSD.
>
> --
> Ron McDowell
> San Antonio TX



Re: earmark on hfsplus port

2010-03-22 Thread Ron McDowell

Ted Roby wrote:

On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:

  

I suspect the OP would like to dual boot his intel mac machine and
still have access from OpenBSD to the files stored on a hfsplus
partition.

   -Otto





This is more in line with what I am seeking.
I have a large amount of data which must be moved over from
hfsplus to ffs. Since I am running -current, and seeking to assist
with development, -my- solution was to invest in another large
SATA drive, and attach via USB. I will format it with FAT32, copy
all desired media from large hfsplus backup volume, boot to openbsd,
copy all that data to internal FFS, reformat new drive FFS and use as
backups.

My desire, however, is to possibly give OpenBSD portable hfsplus
access on i386 for future Mac migrators.
  


A note of caution.  I copied a bunch of stuff from an OSX 10.6 partition 
to a FAT32 USB drive, and when looking at that FAT32 USB drive mounted 
on an OpenBSD 4.7 system, any filenames that fit into the old DOS 
8-character-dot-3-character naming convention got mapped to all 
uppercase.  Played hell with some of my source trees. :(


I'm not sure if that happened on the OSX write to the FAT32 drive or on 
the OpenBSD read from the drive... but it's not going to do what I want.


So yes, Ted, I'd like very much to be able to mount an intel Snow 
Leopard hfs+ file system on OpenBSD.


--
Ron McDowell
San Antonio TX



Re: earmark on hfsplus port

2010-03-22 Thread Ted Roby
On Mon, Mar 22, 2010 at 5:12 PM, bofh  wrote:

> Would be hfs porters should also know that snow leopard (10.6) made
> further extensions to hfs+ and there can be data in a file created on
> 10.6 that even 10.5 can't see.
>
>

Yes. This is why my 10.5 system tools broke, and those third party
companies do not care to update. I have provided tech support for
MacOS far longer than I have ever cared to actually use it.

I can:
1. Learn to develop on Apple. (I'll stick with C, thanks)
2. Turn my Apple into a fink. (screw you stallman) (I'll stick with C,
thanks)
3. Learn to develop on OpenBSD. (I'll stick with C, thanks)

I choose three!

(I also choose three!)



Re: earmark on hfsplus port

2010-03-22 Thread bofh
Would be hfs porters should also know that snow leopard (10.6) made
further extensions to hfs+ and there can be data in a file created on
10.6 that even 10.5 can't see.

On 3/22/10, Dale Rahn  wrote:
> On Mon, Mar 22, 2010 at 11:39:07AM -0600, Ted Roby wrote:
>> On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:
>>
>> >
>> > I suspect the OP would like to dual boot his intel mac machine and
>> > still have access from OpenBSD to the files stored on a hfsplus
>> > partition.
>> >
>> >-Otto
>> >
>>
>>
>> This is more in line with what I am seeking.
>> I have a large amount of data which must be moved over from
>> hfsplus to ffs. Since I am running -current, and seeking to assist
>> with development, -my- solution was to invest in another large
>> SATA drive, and attach via USB. I will format it with FAT32, copy
>> all desired media from large hfsplus backup volume, boot to openbsd,
>> copy all that data to internal FFS, reformat new drive FFS and use as
>> backups.
>>
>> My desire, however, is to possibly give OpenBSD portable hfsplus
>> access on i386 for future Mac migrators.
>>
>
> It should be possible to build the port on i386 with the 'ONLY_FOR' tag
> changed, however I dont recall that the hfsplus code was new enough to
> support case-sensitive filesystems. Testing would need to be done to verify
> what filesystems (hfs/hfs+/journal/case-sensitive) features would work with
> the hfsplus package if the macos partition was cleanly shut down (journal).
> If someone were to do this testing and post a diff to ports@ with such
> testing results, such diff would likely be accepted.
>
> Dale Rahn dr...@dalerahn.com
>
>

-- 
Sent from my mobile device

http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford
learn french:  http://www.youtube.com/watch?v=30v_g83VHK4



Re: earmark on hfsplus port

2010-03-22 Thread Ted Roby
On Mon, Mar 22, 2010 at 1:42 PM, Dale Rahn  wrote:

>
>
> It should be possible to build the port on i386 with the 'ONLY_FOR' tag
> changed, however I dont recall that the hfsplus code was new enough to
> support case-sensitive filesystems. Testing would need to be done to verify
> what filesystems (hfs/hfs+/journal/case-sensitive) features would work with
> the hfsplus package if the macos partition was cleanly shut down (journal).
> If someone were to do this testing and post a diff to ports@ with such
> testing results, such diff would likely be accepted.
>
> Dale Rahn   dr...@dalerahn.com
>


I don't get past make.
The ld complains about libhfsp.so.0.0 with undefined references
to bswap_32, bswap_64 and bswap_16

/usr/local/bin/libtool  --mode=link cc  -O2 -pipe -L/usr/local/lib -o
hpmount  hpmount.o hpcache.o hfsputil.o glob.o dstring.o dlist.o
../libhfsp/src/libhfsp.la -lutf8
mkdir .libs
cc -O2 -pipe -o .libs/hpmount hpmount.o hpcache.o hfsputil.o glob.o
dstring.o dlist.o  -L/usr/local/lib -L../libhfsp/src/.libs -lhfsp -lutf8
-Wl,-rpath,/usr/local/lib
hpcache.o(.text+0x44): In function `hpcache_filename':
: warning: strcpy() is almost always misused, please use strlcpy()
hpcache.o(.text+0x51): In function `hpcache_filename':
: warning: strcat() is almost always misused, please use strlcat()
/usr/local/lib/libutf8.so.1.0: warning: sprintf() is often misused, please
use snprintf()
../libhfsp/src/.libs/libhfsp.so.0.0: undefined reference to `bswap_32'
../libhfsp/src/.libs/libhfsp.so.0.0: undefined reference to `bswap_64'
../libhfsp/src/.libs/libhfsp.so.0.0: undefined reference to `bswap_16'
collect2: ld returned 1 exit status
gmake[2]: *** [hpmount] Error 1
gmake[2]: Leaving directory
`/usr/ports/pobj/hfsplus-1.0.4p2/hfsplus-1.0.4/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/pobj/hfsplus-1.0.4p2/hfsplus-1.0.4'
gmake: *** [all-recursive-am] Error 2
*** Error code 2

Stop in /usr/ports/misc/hfsplus (line 2242 of /usr/ports/infrastructure/mk/
bsd.port.mk).



Re: earmark on hfsplus port

2010-03-22 Thread Dale Rahn
On Mon, Mar 22, 2010 at 11:39:07AM -0600, Ted Roby wrote:
> On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:
> 
> >
> > I suspect the OP would like to dual boot his intel mac machine and
> > still have access from OpenBSD to the files stored on a hfsplus
> > partition.
> >
> >-Otto
> >
> 
> 
> This is more in line with what I am seeking.
> I have a large amount of data which must be moved over from
> hfsplus to ffs. Since I am running -current, and seeking to assist
> with development, -my- solution was to invest in another large
> SATA drive, and attach via USB. I will format it with FAT32, copy
> all desired media from large hfsplus backup volume, boot to openbsd,
> copy all that data to internal FFS, reformat new drive FFS and use as
> backups.
> 
> My desire, however, is to possibly give OpenBSD portable hfsplus
> access on i386 for future Mac migrators.
> 

It should be possible to build the port on i386 with the 'ONLY_FOR' tag
changed, however I dont recall that the hfsplus code was new enough to
support case-sensitive filesystems. Testing would need to be done to verify
what filesystems (hfs/hfs+/journal/case-sensitive) features would work with
the hfsplus package if the macos partition was cleanly shut down (journal).
If someone were to do this testing and post a diff to ports@ with such
testing results, such diff would likely be accepted.

Dale Rahn   dr...@dalerahn.com



Re: earmark on hfsplus port

2010-03-22 Thread Ted Roby
On Mon, Mar 22, 2010 at 11:45 AM, Ted Unangst  wrote:

>
> Getting data off a filesystem can be useful on any machine, even if
> you don't intend to boot it.  Ports are generally marked "only for"
> because they only work there (read: are not written portably), not out
> of a subjective "useful" call.
>


OK! I already suspected a need to "hack" through this problem.

So, does the Darwin license harmonize with OpenBSD? (I suspect it does.)

In this case, it might be more feasible for me to look at Darwin's way of
handling the filesystem.



Re: earmark on hfsplus port

2010-03-22 Thread Ted Unangst
On Mon, Mar 22, 2010 at 1:07 PM, Bryan Irvine  wrote:
> On Mon, Mar 22, 2010 at 9:59 AM, Ted Roby  wrote:
>> I've noticed this environment variable in misc/hfsplus
>>
>>
>> # this only makes sense on macintosh (powerpc) systems.
>> ONLY_FOR_ARCHS= powerpc
>>
>>
>> It used to only make sense on powerpc systems, but Macintosh
>> hardware now uses i386 architecture. Of course, changing this
>> variable is not enough to cause a successful build.
>>
>> Has someone else setup a common way to get misc/hfsplus
>> on i386, and I missed the answer on google?
>>
>> Is there a reason this would be a bad idea?
>>
>> If I "port" this port to i386 would it be warmly accepted?
>
> I'm sure someone else will correct me if I'm wrong.  I believe the
> only reason this is needed on ppc machines is because the openfirmware
> expects an hfs volume to boot from so the bootloader is stored on a
> small hfs partition.  If that's the case this isn't needed on i386
> Macs.

Getting data off a filesystem can be useful on any machine, even if
you don't intend to boot it.  Ports are generally marked "only for"
because they only work there (read: are not written portably), not out
of a subjective "useful" call.



Re: earmark on hfsplus port

2010-03-22 Thread Ted Roby
On Mon, Mar 22, 2010 at 11:30 AM, Otto Moerbeek  wrote:

>
> I suspect the OP would like to dual boot his intel mac machine and
> still have access from OpenBSD to the files stored on a hfsplus
> partition.
>
>-Otto
>


This is more in line with what I am seeking.
I have a large amount of data which must be moved over from
hfsplus to ffs. Since I am running -current, and seeking to assist
with development, -my- solution was to invest in another large
SATA drive, and attach via USB. I will format it with FAT32, copy
all desired media from large hfsplus backup volume, boot to openbsd,
copy all that data to internal FFS, reformat new drive FFS and use as
backups.

My desire, however, is to possibly give OpenBSD portable hfsplus
access on i386 for future Mac migrators.



Re: earmark on hfsplus port

2010-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2010 at 10:07:24AM -0700, Bryan Irvine wrote:

> On Mon, Mar 22, 2010 at 9:59 AM, Ted Roby  wrote:
> > I've noticed this environment variable in misc/hfsplus
> >
> >
> > # this only makes sense on macintosh (powerpc) systems.
> > ONLY_FOR_ARCHS= powerpc
> >
> >
> > It used to only make sense on powerpc systems, but Macintosh
> > hardware now uses i386 architecture. Of course, changing this
> > variable is not enough to cause a successful build.
> >
> > Has someone else setup a common way to get misc/hfsplus
> > on i386, and I missed the answer on google?
> >
> > Is there a reason this would be a bad idea?
> >
> > If I "port" this port to i386 would it be warmly accepted?
> 
> I'm sure someone else will correct me if I'm wrong.  I believe the
> only reason this is needed on ppc machines is because the openfirmware
> expects an hfs volume to boot from so the bootloader is stored on a
> small hfs partition.  If that's the case this isn't needed on i386
> Macs.
> 
> -Bryan

Not completely right. OpenBSD/macppc can boot from a boot loader
stored on a hfs (NOT hfsplus) partition and from a msdos partition on
a mbr partioned disk.

I suspect the OP would like to dual boot his intel mac machine and
still have access from OpenBSD to the files stored on a hfsplus
partition. 

-Otto



Re: earmark on hfsplus port

2010-03-22 Thread Ted Roby
On Mon, Mar 22, 2010 at 11:07 AM, Bryan Irvine  wrote:

>
> I'm sure someone else will correct me if I'm wrong.  I believe the
> only reason this is needed on ppc machines is because the openfirmware
> expects an hfs volume to boot from so the bootloader is stored on a
> small hfs partition.  If that's the case this isn't needed on i386
> Macs.
>
> -Bryan
>

Perhaps I misunderstood the purpose of the package.
I am looking to mount hfs+ volumes (non-journaled, case-sensitive).
This is beneficial to any hybrid or transitional Macintosh.

In a hybrid system, I want the master OS (OpenBSD) to recognize
all partitions.



Re: earmark on hfsplus port

2010-03-22 Thread Bryan Irvine
On Mon, Mar 22, 2010 at 9:59 AM, Ted Roby  wrote:
> I've noticed this environment variable in misc/hfsplus
>
>
> # this only makes sense on macintosh (powerpc) systems.
> ONLY_FOR_ARCHS= powerpc
>
>
> It used to only make sense on powerpc systems, but Macintosh
> hardware now uses i386 architecture. Of course, changing this
> variable is not enough to cause a successful build.
>
> Has someone else setup a common way to get misc/hfsplus
> on i386, and I missed the answer on google?
>
> Is there a reason this would be a bad idea?
>
> If I "port" this port to i386 would it be warmly accepted?

I'm sure someone else will correct me if I'm wrong.  I believe the
only reason this is needed on ppc machines is because the openfirmware
expects an hfs volume to boot from so the bootloader is stored on a
small hfs partition.  If that's the case this isn't needed on i386
Macs.

-Bryan



earmark on hfsplus port

2010-03-22 Thread Ted Roby
I've noticed this environment variable in misc/hfsplus


# this only makes sense on macintosh (powerpc) systems.
ONLY_FOR_ARCHS= powerpc


It used to only make sense on powerpc systems, but Macintosh
hardware now uses i386 architecture. Of course, changing this
variable is not enough to cause a successful build.

Has someone else setup a common way to get misc/hfsplus
on i386, and I missed the answer on google?

Is there a reason this would be a bad idea?

If I "port" this port to i386 would it be warmly accepted?