File - read from EOF

[Mike Bonner]

Thanks for letting me know the limitations of the method I offered.  Now
that you point it out, it makes sense since it'd be rather tough to do a
count of something that isn't entirely accessible beginning to end.

The detailed files method is definitely better.

I guess one could go read a file byte by byte for the sole purpose of
finding the length, but that'd be a silly duplication of effort.

On Sun, May 28, 2017 at 9: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
>