Re: [GNU Autoconf 2.69] OSX autotools: `aclocal.m4' not being output by `autom4te'

[Gary V. Vaughan]

Hi Jeff,

On Jun 27, 2014, at 11:10 AM, Jeffrey Sheen <address@hidden> wrote:

> Thanks for the suggestions Gary.

No problem.

> I do run a NAS on my LAN, and backup from my shared data partition to both 
> Dropbox and Copy (the only cloud storage clients that support symlinks over 
> multiple file system types). These both rely on network connectivity, where 
> the solution I require is a partition on local drive attached to the device.

Assuming this means you need to unmount, detach, walk to another machine, plug, 
mount and then access... you still have a few better options than FAT, I think.

> Is it possible to have a local, NTFS data partition and access it with Samba 
> on a local boot partition? I would have thought that fundamentally you'd need 
> a layer converting Samba I/O calls into NTFS calls, in which case, why not 
> address the NTFS partition directly (functionality which does not exist in 
> OSX).

You answered your own question :)  OSX can mount windows shares, even though it 
can't read an NTFS filesystem (actually I did once find a way to mount NTFS 
read-only on Snow Leopard, so you might want to google that if it seems 
attractive in case it is still maintained and/or improved).  But again, that 
requires at least an adhoc wifi network to connect the OSX client to the 
Windows SMB server, which you seem to have ruled out.

> Synchronising data across multiple local partitions is certainly not more 
> elegant than a single, shared data partition, and would require multiple 
> times the redundancy of storage.

Well, that's hard to say without more context.  But, I have all my open source 
projects checked in to local git repos on a dropbox share, and use them from 
dozens of heterogenous machines scattered across the globe all of which DropBox 
synchronizes invisibly for me... which suits me far better than FAT + sneaker 
net ;-)  But, that only works because I know I'm only working on one machine at 
a time and don't have to worry about merge conflicts.

> With regards to TrueCrypt and PKZip, are these not application layer 
> implementations that create files on top of a file system? If this is not the 
> case, and they have their own file system implementations, then let me know 
> and I will test them.

They create a filesystem in a file on the host filesytem that contains contents 
of the packaged files + metadata (timestamps, ownership etc).  You would either 
pkunzip into a local featureful filesystem, edit and then pkzip back into the 
host filesystem for sneaker net transport to the next machine, or in the case 
of TrueCrypt mount the embedded filesystem from either a disk image in the host 
fs, or from a whole disk image -- lots of details in the TrueCrypt docs.  Be 
careful to avoid the deliberately brain-damaged most recent release though - 
and pick up 6.1a images for all the machines that need to read the TrueCrypt fs.

> Without a viable alternative, I will continue to use a FAT data partition, 
> and temporarily copy source trees onto my boot partition when executing GNU 
> Autotools over them. I can then copy them back, and proceed normally.

In that case, what about hosting the transported files in a VM that boots with 
virtual box or vmware (or other multi-arch compatible VM image format)  on each 
target machine and have the running VM export the shared files over 
sshfs/samba/nfs/all-3! for live mounting and editing on the target machine?

Docker also seems to run on Windows, according to its website:  So a modern 
solution might be to wrap the whole thing up in a docker container on the 
external drive and deploy that on each target machine in turn for access to the 
files it contains.  And with a little extra care you could easily incorporate 
snapshotting and/or backups into the process without additional tools.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

signature.asc
Description: Message signed with OpenPGP using GPGMail