On Sun, May 22, 2016 at 05:22:56PM -0600, Mark Post wrote: > >>> On 5/22/2016 at 10:45 AM, WF Konynenberg <w...@konynenberg.org> wrote: > > In Linux/Unix, a file is simply a byte stream. Any format information > > about a structured file should be accessible to the application by some > > means, so it can know how to parse the file. Since the CMS file system > > stores structured files of different types/modes, this meta information > > in the file system should somehow be made available to applications in > > Linux/Unix when accessing the file system through cms-fuse. There are > > Sounds like you're starting to argue Alan's case here. Have the file system > driver do the heavy lifting for you. I don't think that's likely to happen. > > > various ways to achieve that, e.g. represent each CMS file by 2 files in > > Linux/Unix (similar, I think, to how "resource forks" are handled in > > Apple systems), one containing the data, one containing the meta data, > > or, alternatively, add a header to each file that represents the meta > > data from the file system (though this might break some existing > > applications that currently expect to find only the actual data in the > > file and somehow "magically" know the meta data...), etc, etc. Finding > > the most suitable model will likely require some creative thought on the > > part of the developers. Perhaps the representation model can be made to > > depend on a mount option, with the default being backward compatible > > lack of metadata. > > > > Just simply saying "sorry, this critical meta data from the CMS file > > system is not available in Linux" basically means unnecessarily > > crippling Linux access to the CMS file system. > > Again, Alan's original suggestion was to teach cmsfs-fuse about such things. > > I suppose one could use a combination of cmsfs-fuse and Rick Troth's > wonderful CMSFS package. > > s390vsl204:~ # cmsfs-fuse /dev/dasdg /mnt > s390vsl204:~ # l /mnt > total 34024 > drwxrwx--- 2 root root 512 May 4 18:56 ./ > drwxr-xr-x 1 root root 172 May 18 19:00 ../ > -rw-rw---- 1 root root 160 May 4 17:07 FTPBOOT.PARM > -rw-rw---- 1 root root 34812720 May 4 18:56 INITRAMF.IMG > -rw-rw---- 1 root root 2000 Oct 1 2012 KAKKA2.EXEC > -rw-rw---- 1 root root 2000 Oct 1 2012 KAKKA3.EXEC > -rw-rw---- 1 root root 2000 Oct 1 2012 LINUX.EXEC > -rw-rw---- 1 root root 2000 Oct 1 2012 S11S2GM.EXEC > > s390vsl204:~ # cmsfslst -f /dev/dasdg > FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME > DIRECTOR P0 F 64 8 1 5/04/2016 19:56:38 > ALLOCMAP P0 F 4096 2 2 5/04/2016 19:56:38 > FTPBOOT PARM B1 F 80 2 1 5/04/2016 18:07:40 > S11S2GM EXEC Z1 F 80 25 1 10/01/2012 6:23:36 > KAKKA2 EXEC Z1 F 80 25 1 10/01/2012 6:27:42 > KAKKA3 EXEC Z1 F 80 25 1 10/01/2012 6:28:18 > LINUX EXEC Z1 F 80 25 1 10/01/2012 6:27:00 > INITRAMF IMG B1 F 80 435159 8500 5/04/2016 19:56:38 > > I don't think the file command is going to be extended to handle this, > however.
The cmsfs-fuse also provides information the file mode and format. They can be obtained with getfattr or even set with setfattr. This kind of meta-information is managed as extended file attributes. If there is some indication of packed CMS in these kind of meta-information it could help to spot them in Linux. Of course, if cmsfs-fuse is missing some meta-information it should display with getfattr, please let us know. >From a Linux perspective, I would still consider packed CMS files like any other compressed files like bz2, xz, ... So having a magic to stop these and, optionally, a cmspack/cmsunpack command would help. Thanks and kind regards, Hendrik ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
