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

[John Reagan]

On Thursday, May 20, 2021 at 3:41:32 PM UTC-4, Craig A. Berry wrote:
> 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.
Yikes.  Totally missed that.  I'll add that to the list.
On my nearby RHEL box, I do see:

#if defined __USE_MISC || defined __USE_XOPEN2K8
    /* Nanosecond resolution timestamps are stored in a format
       equivalent to 'struct timespec'.  This is the type used
       whenever possible but the Unix namespace rules do not allow the
       identifier 'timespec' to appear in the <sys/stat.h> header.
       Therefore we have to handle the use of this header in strictly
       standard-compliant sources special.  */
    struct timespec st_atim;            /* Time of last access.  */
    struct timespec st_mtim;            /* Time of last modification.  */
    struct timespec st_ctim;            /* Time of last status change.  */
# define st_atime st_atim.tv_sec        /* Backward compatibility.  */
# define st_mtime st_mtim.tv_sec
# define st_ctime st_ctim.tv_sec
#else
    __time_t st_atime;                  /* Time of last access.  */
    __syscall_ulong_t st_atimensec;     /* Nscecs of last access.  */
    __time_t st_mtime;                  /* Time of last modification.  */
    __syscall_ulong_t st_mtimensec;     /* Nsecs of last modification.  */
    __time_t st_ctime;                  /* Time of last status change.  */
    __syscall_ulong_t st_ctimensec;     /* Nsecs of last status change.  */
#endif