Check if local file has changed [duplicate] - javascript

This question already has answers here:
Check if file has changed using HTML5 File API
(3 answers)
Closed 2 years ago.
I have a web app, where the user can select a local file as input, using the html5 FileReader API. Is there any way I can check if the file has changed, that works in modern browsers?
Historically, this was possible in some browsers by polling the file object and comparing the File.lastModifiedDate (deprecated) or File.lastModified property, as outlined in this QA: Check if file has changed using HTML5 File API. However, the spec says that lastModifiedDate and other file data should be a snapshot of the file as it looked like when the users first selected it, so this should not work (and it seems like recent versions of most browsers indeed follow the spec now, making this hack unavailable).
I was hoping to be able to check for changes by reading the file. This kind of works, but as soon as the file is changed on disk, Chrome and Firefox throw an error saying DOMException: The requested file could not be read, typically due to permission problems that have occurred after a reference to a file was acquired. Is there any way around this?
This is what I tried:
let oldText
setInterval(function () {
const fileObj = document.getElementById('myFileInput').files[0]
const reader = new FileReader()
reader.onload = evt => {
const text = evt.target.result
if (text !== oldText) {
console.log("The file has changed!")
oldText = text
}
}
reader.readAsText(fileObj)
}, 1000)
...or simpler:
const fileObj = document.getElementById('myFileInput').files[0]
const reader = new FileReader()
reader.readAsText(fileObj) // works
// now lets edit the file and try again
reader.readAsText(fileObj) // fails
reader.readAsText() works as expected, until the file is changed, when it throws the error mentioned above. I guess this is a security measure of sorts, though I don't fully understand what it's trying to protect the user from. What can I do instead?

This will be possible again if/when the Native File System API is implemented in browsers. It will be partially enabled in Google Chrome 85, scheduled for release in October 2020.
Unlike the FileReader API it requires a explicit user interaction, so you'd do something like this:
myFileInput.addEventListener('change', async (e) => {
const fh = await window.chooseFileSystemEntries()
// fh is now a FileSystemFileHandle object
// Use fh.getFile() to get a File object
})

Related

Can't read the same file from an Input tag twice using getElemenById + FileReader API

Currently, I'm developing a WebService which user selects a file and we're doing some pre-processing on user's browser later we will send the file to the server.
When a user selects a file from file manager(<input type=file id="dropzone"/>) an event will fire and will load the selected file using FileReaderAPI, when the process is done(it's guaranteed that this section will execute after the first process finished) when I want to read the file again later in the service using document.getElementById("dropzone") it returns the null.
here is the code for the input component, in this case, I'm using react-dropzone.js:(since I'm accessing input element by getElementById it makes no difference which library is used)
const{
acceptedFiles
} = useDropzone({
accept: "video/*, .mkv",
onDrop: files => props.handle()
});
return(<div> <input {...getInputProps()} id="dropzone"/> </div>) ;
props.handle(files) refer to the function which will be doing the file processing
following is a part of handle() function which deals with the selected file and will fire when a user selects a file.
var upFile = document.getElementById("dropzone");
var file = upFile.files[0];
//Original function iterate over all slices
var r = new FileReader();
var blob = file.slice(offset, length + offset);
r.onload = processChunk;
r.readAsArrayBuffer(blob);
Later when I want to access the file again using document.getElementById("dropzone") it returns null
Any Idea for solving this?
After many trials and errors, I found out this is caused by one of the browser's 3rd party security extensions.
Make sure to disable these kinds of extensions in the developing stage.

Reading a text file then setting as variables to use for authentication in Javascript [duplicate]

At the moment, due to the security policy Chromium can not read local files via ajax without --allow-file-access-from-files. But I currently need to create a web application where the database is a xml-file (in the extreme case, json), located in one dir with index.html. It is understood that the user can run this application locally. Are there workarounds for reading xml- (json-) file, without wrapping it in a function and change to js extension?
loadXMLFile('./file.xml').then(xml => {
// working with xml
});
function loadXMLFile(filename) {
return new Promise(function(resolve, reject) {
if('ActiveXObject' in window) {
// If is IE
var xmlDoc = new ActiveXObject('Microsoft.XMLDOM');
xmlDoc.async = false;
xmlDoc.load(filename);
resolve(xmlDoc.xml);
} else {
/*
* how to read xml file if is not IE?
* ...
* resolve(something);
*/
}
}
}
Accessing file: protocol at chromium using XMLHttpRequest() or <link> element without --allow-file-access-from-files flag set at chromium instance launch is not enabled by default.
--allow-file-access-from-files
By default, file:// URIs cannot read other file:// URIs. This is an
override for developers who need the old behavior for testing.
At the moment, due to the security policy Chromium can not read local
files via ajax without --allow-file-access-from-files. But I
currently need to create a web application where the database is a
xml-file (in the extreme case, json), located in one dir with
index.html. It is understood that the user can run this application
locally. Are there workarounds for reading xml- (json-) file, without
wrapping it in a function and change to js extension?
If user is aware that local files are to be used by the application you can utilize <input type="file"> element for user to upload file from user local filesystem, process file using FileReader, then proceed with application.
Else, advise user that use of application requires launching chromium with --allow-file-access-from-files flag set, which can be done by creating a launcher for this purpose, specifying a different user data directory for the instance of chromium. The launcher could be, for example
/usr/bin/chromium-browser --user-data-dir="/home/user/.config/chromium-temp" --allow-file-access-from-files
See also How do I make the Google Chrome flag “--allow-file-access-from-files” permanent?
The above command could also be run at terminal
$ /usr/bin/chromium-browser --user-data-dir="/home/user/.config/chromium-temp" --allow-file-access-from-files
without creating a desktop launcher; where when the instance of chromium is closed run
$ rm -rf /home/user/.config/chromium-temp
to remove the configuration folder for the instance of chromium.
Once the flag is set, user can include <link> element with rel="import" attribute and href pointing to local file and type set to "application/xml", for option other than XMLHttpRequest to get file. Access XML document using
const doc = document.querySelector("link[rel=import]").import;
See Is there a way to know if a link/script is still pending or has it failed.
Another alternative, though more involved, would be to use requestFileSystem to to store the file at LocalFileSystem.
See
How to use webkitRequestFileSystem at file: protocol
jQuery File Upload Plugin: Is possible to preserve the structure of uploaded folders?
How to Write in file (user directory) using JavaScript?
Or create or modify a chrome app and use
chrome.fileSystem
See GoogleChrome/chrome-app-samples/filesystem-access.
The simplest approach would be to provide a means for file upload by affirmative user action; process the uploaded file, then proceed with the application.
const reader = new FileReader;
const parser = new DOMParser;
const startApp = function startApp(xml) {
return Promise.resolve(xml || doc)
};
const fileUpload = document.getElementById("fileupload");
const label = document.querySelector("label[for=fileupload]");
const handleAppStart = function handleStartApp(xml) {
console.log("xml document:", xml);
label.innerHTML = currentFileName + " successfully uploaded";
// do app stuff
}
const handleError = function handleError(err) {
console.error(err)
}
let doc;
let currentFileName;
reader.addEventListener("loadend", handleFileRead);
reader.addEventListener("error", handleError);
function handleFileRead(event) {
label.innerHTML = "";
currentFileName = "";
try {
doc = parser.parseFromString(reader.result, "application/xml");
fileUpload.value = "";
startApp(doc)
.then(function(data) {
handleAppStart(data)
})
.catch(handleError);
} catch (e) {
handleError(e);
}
}
function handleFileUpload(event) {
let file = fileUpload.files[0];
if (/xml/.test(file.type)) {
reader.readAsText(file);
currentFileName = file.name;
}
}
fileUpload.addEventListener("change", handleFileUpload)
<input type="file" name="fileupload" id="fileupload" accept=".xml" />
<label for="fileupload"></label>
use document.implementation.createDocument("", "", null)
instead of new ActiveXObject('Microsoft.XMLDOM').
You can find the API through GOOGLE. Good luck.
If I understand correctly, the deliverable is intended to run locally so you will not be able to set any flags for local file access on a user's machine. Something I've done in a pinch is to pack it up as an executable with something like nw.js and keep the external data files. Otherwise, you're probably looking at loading as script using a JSON schema in a JS file.
I had a similar problem before. I solved by simply embedding the XML file into the HTML using PHP. Since the application is loaded locally from disk, size, cache etc. are not a concern.
If you're using Webpack, you can instead directly import the file using a loader like this or this, in which case the file is included into the resulting bundled javascript.
You can load XML through a string of text using DOMParser, Just load your file and parse the text using the .parseFromString. You could use an if statement containing (window.DOMParser) to check if the DOMParser is supported

Ensuring HTML5 FileReader Performs When .target Content Has Changed Since Last Use

In a website I am using HTML5, rather than .php/forms/ and clientside AJAX, to retrieve files
from my laptop's hard drive. The page, when it loads, has a textarea in which I display the files; but here I also should note that I have other functionality, which permits me to save the contents of the textarea as a new file. That, I do via AJAX. Back to the chase: the "Browse" opens the Dialogue, I select a file, and the HTML5 FileRead fetches the file, all is well.
I can perform that operation as many times as I wish, no problem. But if I then save a new file, when I next go to use the FileReader, it fails. I have been on this for about 14 hours now, trying to discover a reason why the code behaves that way.
Without putting up a wall of code, anyone encountered a similar problem? Ah, and the most annoying of all, is that the Dragonfly inspector is showing the textarea textContent as the proper data, from inside the event.target.result which works so well on the first operations after opening the page.
EDIT ::
Unlike most of the blogs, questions and answers examples and even some spec documentation,
.textContent did not work in the context of the script I am working in, but one change as to
what specifically the data was being written AS, and all the intermittent, on again off again
FileReader behaviour, was resolved and extensive testing shows it performing 100%.
In order to permit use of FileReader in between performing file saves out of the textarea, just had to change textContent to innerText:
reader.onloadend = function(evt) {
if (evt.target.readyState == FileReader.DONE) { // note: DONE == 2
console.log(">>>> 12 <<<< text is : "+event.target.result);
// the textarea being edited // saved from for new files...
// ... and used to display files read by FileReader
document.getElementById("TextAREAx1xMAIN").textContent = event.target.result;
}
};
reader.onloadend = function(evt) {
if (evt.target.readyState == FileReader.DONE) {
console.log(">>>> 12 <<<< text is : "+event.target.result);
// the textarea being edited // saved from for new files...
// ... and used to display files read by FileReader
document.getElementById("TextAREAx1xMAIN").innerText = event.target.result;
}
};

Check if file has changed using HTML5 File API

Okay, so I have a program which outputs some specific data to a tab separated variable file.
I had been using Excel to open and view the file contents, however I found excel's insistence on locking every file it opens to be incredibly annoying as my program would crash if I left the file open in Excel... but I would really like the data to neatly update after each run of the program, so I don't have to close and re-open the file all the time.
So, I decided it would be easiest to use Javascript to parse the file and display it in a html table, and it was. I knocked something together in no time. Now my program doesn't crash if I leave the file on display, however, it still doesn't update... and I have to open the newly generated file each time.
So, I was wondering if there was a mechanism by which my Javascript could be somehow notified of a change to the file by another process? I know this is unlikely, but I would like to avoid simply polling the file for obvious reasons.
I am very familiar with JS, but HTML5 and the new APIs are all new to me.
I don't believe the File API has any event for the file changing, just progress events and the like.
Update August 2020: The alternative below no longer works, and the specification specifically disallows it by saying that the File object's information must reflect the state of the underlying file as of when it was selected. From the spec:
User agents should endeavor to have a File object’s snapshot state set to the state of the underlying storage on disk at the time the reference is taken. If the file is modified on disk following the time a reference has been taken, the File's snapshot state will differ from the state of the underlying storage.
You could use polling. Remember the lastModifiedDate of the File, and then when your polling function fires, get a new File instance for the input and see if the lastModifiedDate has changed.
This works for me on Chrome, for instance: Live Copy | Source
(function() {
var input;
var lastMod;
document.getElementById('btnStart').onclick = function() {
startWatching();
};
function startWatching() {
var file;
if (typeof window.FileReader !== 'function') {
display("The file API isn't supported on this browser yet.");
return;
}
input = document.getElementById('filename');
if (!input) {
display("Um, couldn't find the filename element.");
}
else if (!input.files) {
display("This browser doesn't seem to support the `files` property of file inputs.");
}
else if (!input.files[0]) {
display("Please select a file before clicking 'Show Size'");
}
else {
file = input.files[0];
lastMod = file.lastModifiedDate;
display("Last modified date: " + lastMod);
display("Change the file");
setInterval(tick, 250);
}
}
function tick() {
var file = input.files && input.files[0];
if (file && lastMod && file.lastModifiedDate.getTime() !== lastMod.getTime()) {
lastMod = file.lastModifiedDate;
display("File changed: " + lastMod);
}
}
function display(msg) {
var p = document.createElement('p');
p.innerHTML = msg;
document.body.appendChild(p);
}
})();
<input type='file' id='filename'>
<input type='button' id='btnStart' value='Start'>
There is two solutions to this problem, and <input type="file"> is not one of them. according to the spec, it creates a "snapshot" of the file.
Native File System
This api is experimental and requires flags to be enabled in blink (aka chromium browsers). The idea is that you get a file handle and when you need the file then you call the async "getFile" function to retrieve the actual file.
This feature is a "power feature" and require your site to be secure, and it can't work in sandboxed iframes.
So without testing here is some "code in the dark":
// triggerd on click
async function pickFile () {
const handle = showOpenFilePicker()
let lastModificationTime = 0
async function compare () {
const file = await handle.getFile()
if (file.lastModified > lastModificationTime) {
lastModificationTime = +file.lastModified
console.log(await file.text())
}
}
setInterval(compare, 1000)
}
Get Entry from Drag and drop
Similar to the native file system you can also retrieve a file handle and do the same thing, but this feature works in all browsers today. but this code snippet don't work in stackoverflow since it use some sandboxing do making it incompatible, so here is a fiddle with few comments
function drop(event) {
event.stopPropagation();
event.preventDefault();
// get the file as an fileEntry (aka file handle)
const fileEntry = event.dataTransfer.items[0].webkitGetAsEntry()
let lastModificationTime = 0
async function read (file) {
// use the new async read method on blobs.
console.log(await file.text())
}
function compare (meta) {
if (meta.modificationTime > lastModificationTime) {
lastModificationTime = meta.modificationTime
fileEntry.file(read)
}
}
setInterval(fileEntry.getMetadata.bind(fileEntry, compare), 1000)
}
Edit: there is now also a way to get drag and dropped files as a FileSystemFileHandle that is much nicer to work with
elem.addEventListener('dragover', evt => {
// Prevent navigation.
evt.preventDefault()
})
elem.addEventListener('drop', async evt => {
// Prevent navigation.
evt.preventDefault()
// Process all of the items.
for (const item of evt.dataTransfer.items) {
// kind will be 'file' for file/directory entries.
if (item.kind === 'file') {
const entry = await item.getAsFileSystemHandle();
if (entry.kind === 'file') {
// use same solution as the first Native File System solution
}
}
}
})
While T.J. Crowder's answer is correct, Chrome's implementation appears to break the spec.
Each Blob must have an internal snapshot state, which must be initially set to the state of the underlying storage, if any such underlying storage exists, and must be preserved through structured clone. Further normative definition of snapshot state can be found for files.
When a file is selected the input has a snapshot of the contents at that point. Local changes on disk don't update the snapshot.

Paste Clipboard Images Into Gmail Messages [duplicate]

I noticed a blog post from Google that mentions the ability to paste images directly from the clipboard into a Gmail message if you're using the latest version of Chrome. I tried this with my version of Chrome (12.0.742.91 beta-m) and it works great using control keys or the context menu.
From that behavior I need to assume that the latest version of webkit used in Chrome is able to deal with images in the Javascript paste event, but I have been unable to locate any references to such an enhancement. I believe ZeroClipboard binds to keypress events to trigger its flash functionality and as such wouldn't work through the context menu (also, ZeroClipboard is cross-browser and the post says this works only with Chrome).
So, how does this work and where the enhancement was made to Webkit (or Chrome) that enables the functionality?
I spent some time experimenting with this. It seems to sort of follow the new Clipboard API spec. You can define a "paste" event handler and look at event.clipboardData.items, and call getAsFile() on them to get a Blob. Once you have a Blob, you can use FileReader on it to see what's in it. This is how you can get a data url for the stuff you just pasted in Chrome:
document.onpaste = function (event) {
var items = (event.clipboardData || event.originalEvent.clipboardData).items;
console.log(JSON.stringify(items)); // might give you mime types
for (var index in items) {
var item = items[index];
if (item.kind === 'file') {
var blob = item.getAsFile();
var reader = new FileReader();
reader.onload = function (event) {
console.log(event.target.result); // data url!
};
reader.readAsDataURL(blob);
}
}
};
Once you have a data url you can display the image on the page. If you want to upload it instead, you could use readAsBinaryString, or you could put it into an XHR using FormData.
Edit: Note that the item is of type DataTransferItem. JSON.stringify might not work on the items list, but you should be able to get mime type when you loop over items.
The answer by Nick seems to need small changes to still work :)
// window.addEventListener('paste', ... or
document.onpaste = function (event) {
// use event.originalEvent.clipboard for newer chrome versions
var items = (event.clipboardData || event.originalEvent.clipboardData).items;
console.log(JSON.stringify(items)); // will give you the mime types
// find pasted image among pasted items
var blob = null;
for (var i = 0; i < items.length; i++) {
if (items[i].type.indexOf("image") === 0) {
blob = items[i].getAsFile();
}
}
// load image if there is a pasted image
if (blob !== null) {
var reader = new FileReader();
reader.onload = function(event) {
console.log(event.target.result); // data url!
};
reader.readAsDataURL(blob);
}
}
Example running code: http://jsfiddle.net/bt7BU/225/
So the changes to nicks answer were:
var items = event.clipboardData.items;
to
var items = (event.clipboardData || event.originalEvent.clipboardData).items;
Also I had to take the second element from the pasted items (first one seems to be text/html if you copy an image from another web page into the buffer). So I changed
var blob = items[0].getAsFile();
to a loop finding the item containing the image (see above)
I didn't know how to answer directly to Nick's answer, hope it is fine here :$ :)
As far as I know -
With HTML 5 features(File Api and the related) - accessing clipboard image data is now possible with plain javascript.
This however fails to work on IE (anything less than IE 10). Don't know much about IE10 support also.
For IE the optiens that I believe are the 'fallback' options are
either using Adobe's AIR api
or
using a signed applet

Categories