Any way to mount sparseimages over s3fs ?
Geico Caveman
-stretch�50G�-volname�MacintoshHD�
�
creates�a�sparseimage�
�
$�hdiutil�attach�MacHD.sparseimage�
hdiutil:�attach�failed�-�Illegal�seek�
�
that�I�cannot�mount.�
�
The�image�is�located�on�a�fuse�filesystem�(Amazon�S3�mounted�through�s3fs).
If I create the same image on local hard disk, it mounts without any issues.�
Simon Slavin
forbidden. See the charter. Consider carefully which group
isappropriate to your problem and post just there. Do not multipost.
Simon.
--
I'm using an evaluation license of nemo since 192 days.
You should really try it!
http://www.malcom-mac.com/nemo
Tom Harrington
Geico Caveman <spammer...@spam.invalid> wrote:
> $?hdiutil?create?MacHD?-size?50G?-type?SPARSE?-fs?HFS+?-layout?GPTSPUD??
> -stretch?50G?-volname?MacintoshHD?
> ?
> creates?a?sparseimage?
> ?
> $?hdiutil?attach?MacHD.sparseimage?
> hdiutil:?attach?failed?-?Illegal?seek?
> ?
> that?I?cannot?mount.?
> ?
> The?image?is?located?on?a?fuse?filesystem?(Amazon?S3?mounted?through?s3fs).
>
> If I create the same image on local hard disk, it mounts without any issues.?
Because of the way sparse images work, this is not at all surprising.
Try using a sparse bundle, which will give you the same advantages but
should work in this case.
--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/
Geico Caveman
<t...@pcisys.no.spam.dammit.net> said:
> In article <xyr5m.24415$Wx7....@newsfe04.iad>,
> Geico Caveman <spammer...@spam.invalid> wrote:
>
>> $?hdiutil?create?MacHD?-size?50G?-type?SPARSE?-fs?HFS+?-layout?GPTSPUD??
>> -stretch?50G?-volname?MacintoshHD?
>> ?
>> creates?a?sparseimage?
>> ?
>> $?hdiutil?attach?MacHD.sparseimage?
>> hdiutil:?attach?failed?-?Illegal?seek?
>> ?
>> that?I?cannot?mount.?
>> ?
>> The?image?is?located?on?a?fuse?filesystem?(Amazon?S3?mounted?through?s3fs).
>>
>> If I create the same image on local hard disk, it mounts without any issues.?
>
> Because of the way sparse images work, this is not at all surprising.
> Try using a sparse bundle, which will give you the same advantages but
> should work in this case.
Did not work through Disk Utility (got an illegal seek error).
Through command line:
$ hdiutil create MacHD -size 50G -type SPARSEBUNDLE -fs HFS+ -layout
GPTSPUD -stretch 50G -volname MacintoshHD
hdiutil: create failed - Input/output error
Now I cannot even create anything.
Tom Harrington
Geico Caveman <spammers...@spam.invalid> wrote:
Try creating it on a local disk and then moving it to S3. The command
above should work, and sparse bundles are specifically designed for use
on remote servers.
Geico Caveman
<t...@pcisys.no.spam.dammit.net> said:
Tried that (used encryption this time - this entire business is useless
otherwise).
The transfer hung at 9.1MB / 65MB or so.
I get a popup error (used the GUI for the copy) :
The Finder cannot complete the operation because some data in
"MacHD.sparsebundle" could not be read or written. (Error code -36).
This also unmounts the s3fs fuse mountpoint.
Remounting.
I see a folder there (not an image icon like it was on Desktop).
I can click on the folder to reveal a single folder named bands.
The fact that I can get inside without any popup asking me for the
password (I tested the original sparsebundle - that does ask for a
password) means that the encryption is non-existent.
Filling up the sparse image / bundle locally with Carbon Copy Cloner or
SuperDuper! and then moving it to Amazon S3 is not an option because of
the 5GB upload limit per entity in S3. The hard disk I am trying to
backup is 38GB currently.
I would not mess with any of this at all if duplicity on Mac was not
broken. Macports has an error that prevents duplicity from being built.
This error has been in existence for weeks, if not months. An
intolerable situation that would have been unheard of in Linux.
If I can't even do remote encrypted backups, this whole business is
useless. Sorry about the rant (and you deserve none of it given how
helpful you have tried to be), but I am getting pretty frustrated here.
Tom Harrington
Geico Caveman <spammers...@spam.invalid> wrote:
> Tried that (used encryption this time - this entire business is useless
> otherwise).
>
> The transfer hung at 9.1MB / 65MB or so.
>
> I get a popup error (used the GUI for the copy) :
>
> The Finder cannot complete the operation because some data in
> "MacHD.sparsebundle" could not be read or written. (Error code -36).
>
> This also unmounts the s3fs fuse mountpoint.
Sounds like a bug in s3fs to me, unfortunately. If your MacFUSE is up
to date it might be worth trying JungleDisk. I can't say if it'll help
but it's a different way to get a similar result and probably has
different bugs.
> Remounting.
>
> I see a folder there (not an image icon like it was on Desktop).
>
> I can click on the folder to reveal a single folder named bands.
>
> The fact that I can get inside without any popup asking me for the
> password (I tested the original sparsebundle - that does ask for a
> password) means that the encryption is non-existent.
Not necessarily-- a sparse bundle stores its data in (relatively) small
files called bands, and those are the files that would be encrypted.
Something got messed up, because normally the Finder would know to treat
this folder as a sparse bundle and would mount it as a disk image. But
that's almost certainly related to the issues you had in creating it.
> Filling up the sparse image / bundle locally with Carbon Copy Cloner or
> SuperDuper! and then moving it to Amazon S3 is not an option because of
> the 5GB upload limit per entity in S3. The hard disk I am trying to
> backup is 38GB currently.
FWIW, the default band size in a sparse bundle is 8MB, and the bundle
will use as many as it needs to make up the combined storage in the disk
image. If you can transfer files up to 8MB to a total of at least 38GB
then this approach shouldn't be a problem. One of the main reasons to
use a sparse bundle is to bypass limits like the one you describe.
> I would not mess with any of this at all if duplicity on Mac was not
> broken. Macports has an error that prevents duplicity from being built.
> This error has been in existence for weeks, if not months. An
> intolerable situation that would have been unheard of in Linux.
I'm sure, but such tools are less widely used on Macs and as a result
get less development support.