[…] Is this an intentional change […]? […]Yes, it’s intentional (https://wiki.freepascal.org/User_Changes_3.2.0#FileExists_on_Unix-based_systems).
[…] Is this an intentional change […]? […]Yes, it’s intentional (https://wiki.freepascal.org/User_Changes_3.2.0#FileExists_on_Unix-based_systems).
I think someone made a mistake in their logic of thinking..
from day one of my experience of coding in OSes, everything is a file, even in DOS the director "File" had it's own extension using the the "." or ".." extensions. So with that it was easy to copy a whole directory because it was treated as a single file..
Maybe they may want to revaluate their decision on this ?
I think someone made a mistake in their logic of thinking..
from day one of my experience of coding in OSes, everything is a file, even in DOS the director "File" had it's own extension using the the "." or ".." extensions. So with that it was easy to copy a whole directory because it was treated as a single file..
Maybe they may want to revaluate their decision on this ?
So a symlink is nothing but a file pointing to another file.
Well I've always liked the methodology of LINUX/UNIX of everything is a file because with devices , the last time I did serial on Linux, you had the device which acted as a file (directory tree Device NAME) and then sub files which were a data channel file and the control file and from that you could simply open two files within the directory (Device name) one being the control and one being the data file. Read or write...
The reason for the change is consistency across platforms.
The behaviour on Windows is Delphi compatible.
I will stick to FileAttr I guess for a single function for now..Try FindFirst('C:\', faDirectory, SR) to see if 'C:\' exists and get a nice surprise.
How long has this change been planned? Why aren't the developers using the deprecated/experimental qualifiers or introducing changepending/changedrecently ones?
This statement (https://wiki.lazarus.freepascal.org/User_Changes_3.2.0#FileExists_on_Unix-based_systems) is just WRONG. On UNIX systems a directory IS a file.
Also, the FPC "RenameFile" function also renames directories, but now the FileExists function no longer works for directories.
So WTF are we still going out of our way to conform to Delphi's broken ideas?
[…] I'm […] changing my directory walking code to make both calls where necessary in order to emulate the original behaviour since I'm not confident that switching to DirectoryExists() would always be correct […]Oh dear. You’re changing it by hand? I’d quickly drop in some of my central unit or include file something like:
[…] if FileExists() fails I'm now making a second call to DirectoryExists(). Since this is Linux-specific I think I could probably improve things by making an fpStat() call instead.Walking the SysFS directory tree (https://en.wikipedia.org/wiki/Sysfs) already by itself is a Linux-specific thing. Ergo, there is no benefit in attempting to keep your code cross-platform. Examining an strace(1) of fileExists I see every successful access(2) (https://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html) is (now) followed by a stat(2) (https://pubs.opengroup.org/onlinepubs/9699919799/functions/stat.html) just to filter out any matching directories (“false positives”). In fact, fpAccess(…, F_OK) (https://www.freepascal.org/docs-html/rtl/baseunix/fpaccess.html) would be sufficient for you.
Somebody needs to fix the documentation […]It’s already documented since revision 1730 (https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/sysutils.xml?root=docs&r1=1690&r2=1730).
[…] So a symlink is nothing but a file pointing to another file. […]A symbolic link is a shortcut for typing out a path. A symbolic link may point to non-existent files and can point across file system boundaries. (For the purposes of this statement “file” also includes directories.)
The reason for the change is consistency across platforms.Here we go again. Delphi-compatibility is like the holy grail. To quote trev here:
The behaviour on Windows is Delphi compatible. […]
[…] This is madness.I actually think the change is warranted though, but for the reason of having consistent behavior across all platforms. If Windoze doesn’t deem directories as files, then fileExists should fail on all platforms; there’s directoryExists just for directories.
So WTF are we still going out of our way to conform to Delphi's broken ideas?
Oh dear. You’re changing it by hand? I’d quickly drop in some of my central unit or include file something like:
Walking the SysFS directory tree (https://en.wikipedia.org/wiki/Sysfs) already by itself is a Linux-specific thing. Ergo, there is no benefit in attempting to keep your code cross-platform.
It’s already documented since revision 1730 (https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/sysutils.xml?root=docs&r1=1690&r2=1730).
The documentation is adapted in 3.3.1 and possibly 3.2.1 as back port. Both are FF'ng (op.cit) not releases. The online docs reflect the latest release which is 3.2.0.
You can build the latest docs yourself, though.
When one uses features of a non-release, you will have to build the docs. As simple as that. If you can build the non-releases, like fixes and trunk, you should also be able to build the docs as well. >:D The above is a non-discussion imnsho.
[…] It should be documented.Oh, looooooosen up. The documentation is sometimes buggy. Shit happens. Big deal!
No, it is not buggy - in this case!.Yes, it is. revision 1730 (https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/sysutils.xml?root=docs&r1=1690&r2=1730) was committed on August 2.
Only developers look there.Nope. I and many others do too... that's the point... published docs are strictly tied to releases. Also fixes in docs are tied to fixes or trunk.
I do get MarkMLl’s point: I dare say no ordinary FPC user is regularly checking out and regenerating the latest documentation on their own. I primarily just take the pre-packaged documentation (or what’s on the website (https://freepascal.org/docs.var)), too. There is no point in referring me and others to “But in trunk it’s right. Since August 2.” Only developers look there.
I know for example, you can open a directory with vi, but I have no idea what you happen if I wrote changes to it ....
/home/trev/.fltk/fltk.org:
total used in directory 2 available 322.2 GiB
drwx------ 2 trev wheel 3 3 Jun 2017 .
drwx------ 3 trev wheel 3 3 Jun 2017 ..
-rw-r--r-- 1 trev wheel 94 31 Jan 2019 fltk.prefs
For an application, a file is different to a directory, an application does not care how a directory is treated by the OS, it cares that a directory can contain files, it cannot 'open' a directory to read data, it cannot find multiple files in a file.
If, at an application level, I want to know if a directory exists, it seems sensible to me to use DirectoryExists(). Similarly, for a file, FileExists(). I care not that its Delphi compatible, its sensible in its own right. At an application level.
I do get MarkMLl’s point: I dare say no ordinary FPC user is regularly checking out and regenerating the latest documentation on their own. I primarily just take the pre-packaged documentation (or what’s on the website (https://freepascal.org/docs.var)), too. There is no point in referring me and others to “But in trunk it’s right. Since August 2.” Only developers look there.
I mean, I do, too, but only in cases like this one at hand: When the observed behavior differs from documented (as of at the point of the release) behavior.Only developers look there.Nope. I and many others do too... that's the point... […]
Since a few weeks ago a daily snapshot (https://www.freepascal.org/daily/daily.html) of the documentation is generated so that users can check this more easily.Awesome! But I got disappointed right away, that the RG doesn’t show properly rendered syntax diagrams. :(
Since a few weeks ago a daily snapshot (https://www.freepascal.org/daily/daily.html) of the documentation is generated so that users can check this more easily.Awesome! But I got disappointed right away, that the RG doesn’t show properly rendered syntax diagrams. :(
RG?