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
