On Wednesday 20 Nov 2013 07:42:34 you wrote: > On 2013/11/19 1:51 AM, Mick wrote:
> > I don't know what permissions problems you are talking about... > > Windows kept saying "Hey! That came from an alien system. I'm not going to > let you install it." It would lock stuff and laugh at me. The exact error and method of access when it occurred may be more useful. You may need a different umask in your fstab. I have set up a few Linux machines to mount NTFS and have not had such problems (always in dual booting scenarios). > > ...but you have three main options that I can think of: > > > > 1. A Linux fs, which MSWindows can read. There are MSWindows drivers for > > ext2, but I don't know if they work for 64bit systems, how ACLs translate > > across OS' etc.; > > > > 2. A Linux only fs that MSWindows cannot read, e.g. ext4 and use > > something like SAMBA to serve the files across the OS boundary. > > > > 3. A MSWindows fs like NTFS and use ntfs-3g to mount it from Linux. The > > same would apply with VFAT, although NTFS is more robust. > > > > > > However, although 1 and 3 above will work nicely when dual booting, with > > concurrent access to the same fs from two different OS' you are asking > > for trouble. File locks may be violated if you try to write to the same > > file and data become corrupted. > > That will never happen. Windows will never write to either the shared > download directory or the shared maildir. Why? Because the Windows Host > has no Internet. No Internet, no download. No Internet, no email. Get it? > Download and Email only from Linux, but accessible to Windows - just not > writable in Windows. When you open a file the access timestamp changes. I assume that you will open a message file with a MSWindows mail client. This will modify the file metadata. I don't know the impact of this, hence I thought of warning you. If you decide to respond to a message in MSWindows with your mail client you could have it queued up in your corresponding Linux OS spool file, until you send it (manually or automatically) through Linux. Trying to edit it through both OS concurrently could mess up your file. Again I have not tried it to know what may happen. You may never to try do this, but if you forget that you are editing the file in one OS and then try to edit via another, things may go wrong. > > You may be able to set up special file or directory > > locking through some shell script in Linux, or EMCO MoveOnBoot on > > MSWindows, but I would leave this as an exercise for a rainy day. > > Not needed. > > > This leaves option 2, SAMBA as a plausible solution - application rather > > than fs level access from MSWindows. However, I have never used SAMBA > > in this operating context... > > Errmmm... I thought that Samba WAS the file system interface to Windows. No, it is not. The conventional file system interface you are referring to is the filesystem drivers (MSDOS, ntfs kernel driver and ntfs-3g) that the Linux OS uses to access MSWindows fs types, or the drivers that the MSWindows OS uses to access Linux fs types. Samba is a file server. It accesses files natively on a Linux fs and then it passes these on over the ethernet using TCP/IP (at the application-layer of the OSI model) to MSWindows clients. In this model the MSWindows OS does not read or access the Linux fs at an OS level, the SAMBA server does. > Isn't Samba an SMB compatible interface for Linux filesystems? You know: > Looks like a Linux user to the Linux filesystem, looks like an SMB server > to the Windows OS. No, unless you prefer to define a filesystem interface at an application level. Typically one would refer to fs drivers rather than applications. > > ...and don't know what would happen if both OS tried to write > > to a file concurrently > > Again, that will never happen. Don't worry about it. To Windows, the shared > stuff might as well be read-only. This will be the case if the fs is only accessed via one OS (e.g. Linux) and the files are served to the MSWindows via SAMBA. In which case the solution you seek is probably SAMBA. HTH. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
