>>> On 5/22/2016 at 10:45 AM, WF Konynenberg <[email protected]> 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.
Mark Post
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] 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/
