File - read from EOF
bonnmike at gmail.com
Sun May 28 11:45:39 EDT 2017
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:
> 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
> 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:
More information about the Use-livecode