Race condition in mtime-precision/probe

[julien-f]

Two parallel calls, cachedPrecision is not defined in both, both will call utimes then stat, and Object.defineProperty will be called twice.

This does not throw TypeError: Cannot redefine property because the new value to be defined is the existing value.

[julien-f]

The problem can appear though if trying to lock files on different fs with different precisions.

Maybe that should be a separate issue though.

[satazor]

Hello @julien-f, if I understood correctly, the precision can vary when locking different paths that are associated with different file systems, is that correct?

In those situations, Object.defineProperty can throw or maybe a previous precision will be used which is wrong.

I’m not sure if we can do much here. There are a few options:

• Issue a big warning in the README to provide a different options.fs (like cloning it or using Object.create) if you are using different filesystems.
• Create a new options where you provide paths to different filesystems. We will use this to calculate the precision for each and save it in an object where keys are the paths and values are the precision.
• Completely disable caching but things will slow down.

[julien-f]

the precision can vary when locking different paths that are associated with different file systems, is that correct?

Yep.

IMHO, those duplicate calls to Object.defineProperty are incorrect but it may work well enough as it is to avoid the complexity of deduplicating probing.

I see a possible alternative to your ideas: the precision could be cached per device (fs.Stats#dev).

[satazor]

Didn’t know about the device. It seems we can indeed use that. Are you open to do a PR?