File - read from EOF

[JB]

Thanks, Richard

JB


> On May 28, 2017, at 8:26 AM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>