[Info-vax] scp or sftp: file is "raw", needs to be parsed - possible to work around that?

[Craig A. Berry]

On 5/20/21 2:06 PM, John Reagan wrote:
> On Thursday, May 20, 2021 at 2:14:54 PM UTC-4, Craig A. Berry wrote:
> 
>> Right. Although it might be surprising to some people that compiling
>> with /DEFINE=(_USE_STD_STAT=1) gives you a stat struct that conforms to
>> an older standard rather than any recent one. And it's still a
>> portability problem.
>>
> 
> Huh?  The latest POSIX standard (issue 7, 2018) says:
> 
> The <sys/stat.h> header shall define the stat structure, which shall include at least the following members:
> 
> dev_t st_dev            Device ID of device containing file.
> ino_t st_ino            File serial number.
> mode_t st_mode          Mode of file (see below).
> nlink_t st_nlink        Number of hard links to the file.
> uid_t st_uid            User ID of file.
> gid_t st_gid            Group ID of file.
> [XSI][Option Start]
> dev_t st_rdev           Device ID (if file is character or block special).
> [Option End]
> off_t st_size           For regular files, the file size in bytes.
>                          For symbolic links, the length in bytes of the
>                          pathname contained in the symbolic link.
> [SHM][Option Start]
>                          For a shared memory object, the length in bytes.
> [Option End]
> [TYM][Option Start]
>                          For a typed memory object, the length in bytes.
> [Option End]
>                          For other file types, the use of this field is
>                          unspecified.
> struct timespec st_atim Last data access timestamp.
> struct timespec st_mtim Last data modification timestamp.
> struct timespec st_ctim Last file status change timestamp.
> [XSI][Option Start]
> blksize_t st_blksize    A file system-specific preferred I/O block size
>                          for this object. In some file system types, this
>                          may vary from file to file.
> blkcnt_t st_blocks      Number of blocks allocated for this object.
> [Option End]
> 
> Notice that it says "shall include at least the following members".
> 
>  From the current <stat.h> in the __USING_STD_STAT section
> 
> struct stat {
>      __dev_t     st_dev;     /* device id */
>      __ino_t     st_ino;     /* file number */
>      __mode_t    st_mode;    /* file mode */
>      __MODEFILL( st_mode)
>      __nlink_t   st_nlink;   /* number of hard links */
>      __uid_t     st_uid;     /* user id */
>      __gid_t     st_gid;     /* group id */
>      __dev_t     st_rdev;
>      __off_t     st_size;    /* file size in bytes */
>      __time_t    st_atime;   /* file access time */
>      __TIMEFILL( st_atime)
>      __time_t    st_mtime;   /* file mod time */
>      __TIMEFILL( st_mtime)
>      __time_t    st_ctime;   /* file creation time */
>      __TIMEFILL( st_ctime)
>      char        st_fab_rfm; /* record format */
>      char        st_fab_rat; /* record attributes */
>      char        st_fab_fsz; /* fixed header size */
>      char        st_fabFill;
>      unsigned    st_fab_mrs; /* record size */
>      blksize_t   st_blksize; /* filesystem-specific preferred I/O block size for this file */
>      blkcnt_t    st_blocks;  /* number of blocks allocated for this file */
>      char        st_reserved[sizeof(__int64)*__STD_STAT_QWORDS_RESERVED];
> };
> 
> #   pragma __member_alignment __restore
> 
> #else /* end of __USING_STD_STAT section */
> 
> We provide every field that POSIX defines plus a few more.

Close, but not quite.  Specifically, not the timestamps.  VMS has, for
example:

time_t    st_atime

POSIX has:

struct timespec st_atim

No "e" at the end, and it's a struct that has both second and nanosecond
components.  Most implementations would, for backward compatibility,
define the following:

#define st_atime st_atim.tv_sec

But I have encountered code that used the timespec members directly and
of course didn't work out of the box on VMS.

At first glance it looks like the __TIMEFILL padding in the VMS stat
struct would allow you to overlay a timespec struct on top of a time_t
value in a binary compatible way as long as you are not using 64-bit
time_t (which I believe was never implemented); if it is ever
implemented, there will be no way to avoid binary-incompatible changes
to the stat struct if simultaneously changing the timestamps from time_t
to timespec.

Whether nanosecond precision is available from the file system is a
different question. But there would be source compatibility advantages
even if the nanosecond portion is rounded to the nearest 10-millisecond
tick or something.