Hi Jeff, On Jun 27, 2014, at 11:10 AM, Jeffrey Sheen <jeff@xxxxxxxxxxxxxxxxxxx> 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)
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
