File - read from EOF

[Richard Gaskin]

Mike Bonner wrote:

 > On Sat, May 27, 2017 at 7:23 PM, JB wrote:
 >> I want to read a file as binary of any
 >> size but as crazy as it sounds I want
 >> to read in sections form the EOF and
 >> stop at the beginning of the file instead
 >> reading from the start to EOF.
 >>
 >> I have no problems opening, reading and
 >> closing files or reading in sections.
 >>
 >> Does anyone know the easiest way
 >> to determine when I reach the start
 >> of the file similar to using EOF to
 >> stop reading at the end of the file?
 >
 >
 > I think you need to do the following
 >
 > First get the length in bytes of the file
 > get the number of bytes in url ("binfile:" & yourfile)

That'll work well for files that can fit comfortably into memory, but 
IIRC using "URL" will effectively do a sort of "GET", reading the file 
from disk.

And of course, if the file's contents fit comfortably in memory, the 
subsequent operations to obtain sections of it would be much faster if 
done on that copy.

For files larger than can be comfortably worked on in RAM, we currently 
have no truly efficient way to do this, only ways that vary in degrees 
of inefficiency. :)

What would be ideal is to use the OS-provided APIs for obtaining file 
info for a specific file, but in LC right now we only have a way to get 
that info (and LOTS of other info!) for all files in a directory at once.

When a folder contains only a few files it's not much of a problem, but 
with thousands of files it's far less efficient than if the request -hh 
submitted for single-file info were implemented:
http://quality.livecode.com/show_bug.cgi?id=18010

Given how often this comes up in the forums, and the general tediousness 
of having to get/set the working directory and parsing "the detailed 
files", hopefully that'll be done soon.

In the meantime, I use this function to obtain specific file info for a 
given file:


function fwFileInfo pFilePath, pElem
    -- For the file specified in pFilePath, returns the metadata element
    -- specified in pElem, where pElem is one of:
    --    name = short file, URL-encoded
    --    size = data fork size, in bytes
    --    resSize = resource fork size, in bytes (macOS only)
    --    creationDate = creation date in seconds
    --    modDate = last modification date, in seconds
    --    accessDate = last access date, in seconds
    --    backupDate = last backup date, in seconds
    --    userOwner = User owner (Linux and macOS only)
    --    groupOwner = Group owner (Linux and macOS only).
    --    permissions = Unix-style permissions (Linux and macOS only)
    --    macType = MacOS Classic creator and type codes (macOS only).
    -- If no valid element is specified the full comma-delimited entry
    -- for the file is returned.
    --
    local tFileName, tSaveDir, tFileList, tElems, tElemN
    --
    set the itemDelimiter to "/"
    put urlEncode(last item of pFilePath) into tFileName
    delete last item of pFilePath
    put the directory into tSaveDir
    set the directory to pFilePath
    put the detailed files into tFileList
    set the directory to tSaveDir
    filter tFileList with tFileName &",*"
    --
    set the itemdel to ","
    put "name,size,resSize,CreationDate,ModDate,AccessDate," & \
      "BackupDate,"UserOwner,GroupOwner,Permissions,MacType" into tElems
    put itemoffset(pElem, tElems) into tElemN
    if tElemN = 0 then
       return tFileList
    else
       return item tElemN of tFileList
    end if
end fwFileInfo


This is similar to the one Jan posted this morning for obtaining file 
size at 
<http://lists.runrev.com/pipermail/use-livecode/2017-May/237682.html>, 
but unfortunately that function overlooks one of the many details of 
this that make this task so tedious:

On macOS it's common for some older folder metadata files to have CRs in 
their names, which would break the formatting of the CR-delimited return 
value.  File names may also contain commas, which would similarly break 
the comma-delimited rows in that return value.

To counter these, the file and folder names returned with the "detailed" 
lists are URL-encoded, which does a fine job of handling characters 
which would break the output format, but requires us to keep that in 
mind and convert the incoming short file name when filtering from the list.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com