Repository navigation
utimes no work #30212
Description
Am I the only one seeing this?
$ node --experimental-modules src/fsPromisesUtimes.js
(node:86710) ExperimentalWarning: The ESM module loader is experimental.
{ platform: 'darwin', version: 'v12.12.0' }
Actual: 2262-04-11T23:47:16.855Z expected: 2019-01-01T00:00:00.000Z
Completed successfully
And if there is a new promises api in 2019Z, why:
- Is there no nanoseconds that Linux has had since 2009
- birthdate available since 2012
- why do I have to set all times and not only mtime?
/*
© 2019-present Harald Rudell <harald.rudell@gmail.com> (http://www.haraldrudell.com)
This source code is licensed under the ISC-style license found in the LICENSE file in the root directory of this source tree.
*/
// node --experimental-modules src/fsPromisesUtimes.js
import {promises} from 'fs'
const {utimes, writeFile, stat} = promises
import {inspect} from 'util'
const file = 'deleteMe.txt'
const timeval = Date.UTC(2019) // 2019-01-01T00:00:00.000Z
const comment = process.argv.length >= 2 ? process.argv[2] : ''
const log = console.error
testUtimes({file, comment, timeval, log})
.then(resolution => console.error('Completed successfully'))
.catch(reason => console.error(`Error handler:\n${inspect(reason)}`) + process.exit(1))
async function testUtimes({file, comment, timeval, log}) {
const {platform, version} = process
log({platform, version, ...comment ? {comment} : null})
await writeFile(file, '')
await utimes(file, timeval, timeval)
const {mtime} = await stat(file)
log(`Actual: ${mtime.toISOString()} expected: ${new Date(timeval).toISOString()}`)
}
Activity
mscdex commentedon Nov 2, 2019
It's probably a documentation issue if anything. If you pass a positive, finite, numeric value for a date/time argument to
utimes()(or any otherfsAPI that has date/time parameters), it's assuming the value is a UNIX timestamp in seconds.Date.UTC()returns a UNIX timestamp in milliseconds.bnoordhuis commentedon Nov 2, 2019
Not portable across platforms.
Libuv currently rounds down the timestamp to microseconds for consistency across platforms. That's something that could be reconsidered but that should be discussed over at libuv/libuv.
Birthtime is reported on the
fs.Statobject when your kernel is new enough and the file system supports the notion of birth time. You can't modify it, of course.haraldrudell commentedon Nov 2, 2019
Different file systems on a given system are not portable either. I suggest a best-effort approach where nanoseconds and birth dates are supported whenever possible. People who really want it right can read written data back and throw exception if they are different. ie. owner not supported, time resolution 2 seconds
Another thing I have struggled with is illegal Unicode filenames, which legacy file systems are happy to store. For apis that deal with filenames, all filename arguments must have an option of Buffer format, for the case that the filename cannot be represented in an ECMAScript utf-16 string. The two problem areas are illegal utf-8 byte sequences on-disk and non-NFC normalized characters
Anyhow, those bug reports make me look a fool
bnoordhuis commentedon Nov 3, 2019
FWIW, discussion about file path encodings goes back to 2010. It's 2019 now and it still hasn't been resolved. :-)