Re: File size
On Monday, 21 August 2023 at 11:05:36 UTC, FeepingCreature wrote: Can you print some of the wrong sizes? D's DirEntry iteration code just calls `FindFirstFileW`/`FindNextFileW`, so this *shouldn't* be a D-specific issue, and it should be possible to reproduce this in C. Yes! I will get that information tomorrow.
Re: Mach status support
On Monday, August 21, 2023 2:54:02 PM MDT Sergey via Digitalmars-d-learn wrote: > When I worked with one C code translation, I found that command > clock_gettime, that available in POSIX systems is not implemented > in MacOS. > This SO thread > > https://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac > -os-x > > suggested some workaround implementations, which using some mach > headers like mach.h and mach_time.h > > But when I’ve checked dmd sources > > https://github.com/dlang/dmd/tree/master/druntime/src/core/sys/darwin/mach > > I didn’t find it. So currently I’ve used MonoTime as temporary > solution (however I’m not sure if it is a proper alternative). MonoTime is the system-agnostic D solution for getting the time from the system's monotonic clock, whereas Clock.currTime / Clock.currStdTime in std.datetime.systime is the system-agnostic D solution for getting the current wall clock time. Unless you're doing something really specific, you almost certainly should just be using those and not trying to call system-specific functions to get the time. In the case of Darwin systems, core.time declares the appropriate C bindings for the mach stuff so that MonoTime can use them, but they really should be moved to the appropriate place in druntime for Darwin-specific bindings. > How full is dmd specific implementation of Darwin and Mach > headers? > Any plans to improve it (in case it is not full right now)? In general, system-specific bindings get added to druntime, because someone who needed them took the time to add them to the right place in druntime rather than there being an organized effort to add bindings to druntime. - Jonathan M Davis
Mach status support
When I worked with one C code translation, I found that command clock_gettime, that available in POSIX systems is not implemented in MacOS. This SO thread https://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x suggested some workaround implementations, which using some mach headers like mach.h and mach_time.h But when I’ve checked dmd sources https://github.com/dlang/dmd/tree/master/druntime/src/core/sys/darwin/mach I didn’t find it. So currently I’ve used MonoTime as temporary solution (however I’m not sure if it is a proper alternative). How full is dmd specific implementation of Darwin and Mach headers? Any plans to improve it (in case it is not full right now)?
Re: File size
On Monday, 21 August 2023 at 07:52:28 UTC, harakim wrote: I have been doing some backups and I wrote a utility that determines if files are an exact match. As a shortcut, I check the file size. So far so good on this with millions of files until I found something odd: getSize() and DirEntry's .size are producing different values. ... It seems really odd that getSize(sourceFile.name) is returning a different number than sourceFile.size. This is an external HDD on windows formatted in ntfs that it is reading. I believe I originally wrote the files to the file system in Windows, but then today I cut and paste them (in the same drive) in Linux. However, this is the first time this has happened after millions of comparisons and it only happened for about 6 files. It does happen consistently though. I have verified that the file size is that reported by getSize and not sourceFile.size and that the files open correctly. ... Can you print some of the wrong sizes? D's DirEntry iteration code just calls `FindFirstFileW`/`FindNextFileW`, so this *shouldn't* be a D-specific issue, and it should be possible to reproduce this in C.
File size
I have been doing some backups and I wrote a utility that
determines if files are an exact match. As a shortcut, I check
the file size. So far so good on this with millions of files
until I found something odd: getSize() and DirEntry's .size are
producing different values.
This is the relevant code:
```
if (sourceFile.size != getSize(destinationFilename)) {
if (getSize(sourceFile.name) != getSize(destinationFilename))
writeln("Also did not match");
else
writeln("Did match so this is odd");
return ArchivalStatus.SizeDidNotMatch;
}
```
Whereas before it just returned SizeDidNotMatch, now it also
prints "Did match so this is odd".
It seems really odd that getSize(sourceFile.name) is returning a
different number than sourceFile.size. This is an external HDD on
windows formatted in ntfs that it is reading. I believe I
originally wrote the files to the file system in Windows, but
then today I cut and paste them (in the same drive) in Linux.
However, this is the first time this has happened after millions
of comparisons and it only happened for about 6 files. It does
happen consistently though.
I have verified that the file size is that reported by getSize
and not sourceFile.size and that the files open correctly.
This is my compiler version:
DMD32 D Compiler v2.104.2-dirty
If this is actually a problem and I'm not missing something, I
would not mind trying to fix this whenever I have some time.
