fsStat class instance returns mtime, atime and ctime date objects, but there seems to be API only for changing mtime and atime (last modification and access i guess). How can i change creation time to create exact copy of file as it'd be also created the same time as original one?
It's not possible at present with Node itself, but you can use https://github.com/baileyherbert/utimes (a native add-on for Node) to change the creation time (aka btime) of a file on Windows and Mac.
tl;tr: That's not possible atm (Node.js <= v6).
Even though, fs.stat() returns the birthtime of files:
birthtime "Birth Time" - Time of file creation. Set once when the file is created. On filesystems where birthtime is not available, this field may instead hold either the ctime or 1970-01-01T00:00Z (ie, unix epoch timestamp 0)…
Prior to Node v0.12, the ctime held the birthtime on Windows systems. Note that as of v0.12, ctime is not "creation time", and on Unix systems, it never was.
Updating is not possible. From https://github.com/joyent/node/issues/8252:
fs.utimes uses utime(2) (http://linux.die.net/man/2/utime), which doesn't allow you to change the ctime.
(Same holds for birthtime)
The fs.utimes and fs.utimesSync methods are built into Node.js core. See https://nodejs.org/api/fs.html#fs_fs_utimes_path_atime_mtime_callback
Note:
The value should be a Unix timestamp in seconds. For example, Date.now() returns milliseconds, so it should be divided by 1000 before passing it in.
To convert a JS Date object to seconds:
new Date().getTime()/1000|0
Related
I am working on a project where we are migrating from Open VMS to Unix/Linux.
There's a functionality called "FDL" in open vms, which i want to achieve in Unix.
What FDL actually does is , it defines a certain set of attributes for a file or a record, like fixing some block size for a particular file, file organization as sequential, variable or relative, specifying record size in a file beforehand, specifying carriage return(escape sequence) for record etc.
How can i set these attributes before a file gets created in unix.
FDL is merely a syntax/descriptive method to set/view OpenVMS file attributes (metadata) which has no equivalent in typical Linux file systems. Those attributes are implemented by the (Files-11 / ODS) file system an acted on by RMS (the OpenVMS Record management Services) for which again there is no equivalent in Linux although there are packages (sector7).
So much more than an FDL question , this is an RMS question.
RMS offers 'record' access where a record is a blob of byte defined in the file which can be read sequentially, by number or by key (indexed file). The attributes mentioned in the question are to do with simple sequential access, but there Linux just offers a byte-stream method. The application is supposed to know how much to read / when to stop reading. Possibly a (record) terminator like (frequently) (linefeed) is used but that's about it (fscanf).
Other than using a 'parallel' meta file, or reserving an initial byte stream in your files there is no standard way to store metadata on how to use the bytestream in the file, and making them hard to use by other applications.
All this to say: No Can Do.
Sorry.
I'm working with nlpcraft to build a parsing system for scheduling. Users are asked when they will be doing certain activities and they can respond with relative or absolute dates, such as "tuesday and wednesday" or "not until 8/15".
While nlpcraft has very nice relative date parsing, near as I can tell it always parses dates relative to the current system time in UTC. Not only does this complicate testing (because the input is relative while the output is absolute), it means that if the server does not parse the input close to the time the user wrote it, relative dates may be parsed incorrectly. For example, if the user says "tomorrow" at 11PM on a Sunday, but the server doesn't parse it until 5AM on Monday, it might result in Tuesday instead of Monday.
I looked into NCDateEnricher where this all seems to happen and then parsing routine computes a base time as the current system time. I didn't see a way to override this with a config variable or request parameter -- am I missing something?
UTC time server on server-side allows users to easily convert times to local timezone. It's the simplest way to support different timezone users with one server.
If you aren't satisfied with nlpcart provided date NER, you can look at date/time NERS from opennlp/stanford/spacy/google, which can be simply used with nlpcraft system (https://nlpcraft.incubator.apache.org/integrations.html)
I'd like to use 'perf' to measure real execution time of a function. 'perf script' command gives timestamp when the function is called.
Xorg 1523 [001] 25712.423702: probe:sock_write_iter: (ffffffff95cd8b80)
The timestamp field's format is X.Y. How can I understand this value? Is it X.Y seconds?
X.Y is the timestamp in units of seconds.microseconds.
How this value is displayed can be looked at here. You can pass the switch --ns to perf script to display the timestamps in seconds.nanoseconds format too.
To understand this value, you need to understand how the perf module calculates timestamps. You can associate each event with a different clock function to compute the timestamps. By default, perf uses sched_clock function to compute timestamps for an event, more details here.
event->clock = &local_clock;
But you can use the -k switch along with perf record command to associate an event with various clockids.
-k, --clockid
Sets the clock id to use for the various time fields in the
perf_event_type records. See clock_gettime(). In particular
CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are supported, some
events might also allow CLOCK_BOOTTIME, CLOCK_REALTIME and
CLOCK_TAI.
Adding the -k switch to perf record command will enable various clock functions depending on which clockid you use, as can be seen here.
sched_clock function shall return the number of nanoseconds since the system was started. A particular architecture may or may not provide an implementation of sched_clock() on its own. The system jiffy counter will be used as sched_clock(), if a local implementation is not provided.
Note that, all of the above code snippets are for Linux kernel 5.6.7.
X.Y is the raw format of the date. The perf's time function, which operates in nanoseconds, needs to be converted to a human readable format. Use this website to convert it to date, http://www.timestamp.fr/ , or using bash
date -d #25712
I know this might be a simple question but I'm not sure how to solve it.
When I run this bit of code on my local machine
if (someDateTime < DateTime.Now)
// do something
'DateTime.Now' gives me the current date time for my time zone, but when I run it in Azure 'DateTime.Now' gives me a different time
ex. local machine says 12:00AM and Azure says 8:13AM
What do I need to do to compare a time 'someDAteTime' with a time for a user on my site (his/her current DateTime.Now) ?
There should be a Utc() method on that DateTime instance, every programming language has something similar since probably the Atari.
If this is .NET (Full/Core), just use DateTime.UtcNow.
More on that here —
What is the difference between DateTime.UtcNow and DateTime.Now.ToUniversalTime()
The essence here is that you always compare UTC time to UTC time, disregarding zone shift. Moreover, all Azure services report time in UTC "out of the box".
I assume that you are using javascript at client side.
If you want to compare dates you should always use ISO Date (https://en.wikipedia.org/wiki/ISO_8601)with a timezone.
You can use this library in order to use different time zones: https://momentjs.com/timezone/
And this library to compare dates:
https://momentjs.com/
Please take care that the user can modify the date on the client side, so if you need to validate a date for a critical feature you should do this validation on the server side.
On a Linux system (the one in front of me is an Ubuntu 10.04, but that shouldn't matter), how can I tell which of two files created within the same second was created first? The process I control creates neither itself; in all other respects the ctime would, I think, do the trick, but the 1 second resolution is a problem.
For background, I'm trying to reliably determine whether a potentially stale pidfile refers to the current process with that pid. If there's a better way to do that, I'm all ears.
Actually, on modern Unices with modern filesystems, the file modification time is stored in a timespec. Details:
The standard says stat looks like this WRT times:
struct timespec st_atim Last data access timestamp.
struct timespec st_mtim Last data modification timestamp.
struct timespec st_ctim Last file status change timestamp.
And a timespec
time_t tv_sec seconds
long tv_nsec nanoseconds
So, doing a stat on my Linux 2.6.39:
Access: 2011-07-14 15:38:20.016666721 +0300
Modify: 2011-06-10 03:06:12.000000000 +0300
Change: 2011-06-17 11:01:35.416667110 +0300
In conclusion, I think you've got enough precision there if the hardware is supplying it.
You can try ls -rt to sort the files by time on the hope that the file header has more precision than the default list time format displays. But if the file system doesn't have the information, there is no way to do this.
Other options? You could add an ID to the file and always increment it but as soon as you try to load this ID from the file system (when you create a new process), you'll run into problems with locking.
So how can you make sure the PID file is not stale? Answer: Use the daemon script. It runs a process in the background and makes sure the PID file gets deleted as soon as the process exits.