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