As root under Solaris, you can. This has been a nasty cause of surprise for decades. I can't vouch that it has not changed in _very_ recent years, but there certainly will systems be around where thi
Thank you for helping me. Robert M. Goldman Send Emacs-devel mailing list submissions to address@hidden To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnu.org/mailman/listinfo
Yes, something like that. We always do a CHECK_STRING in those cases, at least for the arguments of the primitives; maybe we should have CHECK_FILENAME or something.
So you're suggesting that each use of a system function with such limitations be preceded by "if (contains_null(string)) error ();" or something? I suppose, though it seems such an obscure issue that
Yes, it is (IMO): directory "address@hidden" does not exist, so you should have got an error. Instead, you silently open a directory by another name, as if "address@hidden" existed.
Perhaps most of the places where we use these paradigms are okay due to all these subtle corners that together make everything work. But IMHO it's inherently unsafe to use character arrays that are
Of course. But is the equivalence between "foo" and "address@hidden" fundamentally worse than the (almost: consider symlinks) equivalence between "foo" and "foo/"? Maybe it just doesn't matter much.
That's not what I meant. What I meant is the problem that could happen if encoded_dir's value was address@hidden, and there was also a directory called "foo". Won't we then opendir "foo"? And what i
I'm not sure about any piece of code, no. Bugs are common. But my reading of allocate_string_data starts by: /* Set up Lisp_String S for holding NCHARS characters, NBYTES bytes, plus a NUL byte at t
That's a limitation of opendir (and posix filenames in general), and there's absolutely nothing we can do it (so there's no point in worrying about that case), but we shouldn't introduce new limitati
But then a gazillion other places are buggy: we _do_ use SDATA(str) as a C string, and pass it to functions that will stop examining the string on the first null. A random example: d = opendir (SDAT
As said Andreas, this would stop at the first NUL, which may appear within the string. The +1 is precisely used to make sure we copy the terminating NUL. Stefan
Hmm... removable media... I think it should still be considered as non-remote, although accessing a USB stick after you removed it (but without unmounting it) may hang just like accessing a dead NFS
It is necessary because SBYTES does not count the extra NUL character. E.g., SBYTES (empty_unibyte_string) == 0, and *(SDATA (empty_unibyte_string)) == '\0'. YAMAMOTO Mitsuharu address@hidden
Just because strings are always NUL terminated does not mean that every NUL terminates a string. Andreas. -- Andreas Schwab, address@hidden GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 21
Aha. But it sounds like it's not just me who is confused. Here's just two examples: From doc.c: strp = SDATA (string); while (strp < SDATA (string) + SBYTES (string)) (why not "while *strp"?) From f
See allocate_string_data. Not in the last 18 years. :-) Andreas. -- Andreas Schwab, address@hidden GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something compl
Well, filesystems _shouldn't_ be slow, though some are ;-) But yes, I agree that ``filesystem'' is a kind of misnomer, although some filesystems are associated with very specific devices.
The code in is_slow_fs considers only fixed disks and RAM disks not ``slow''. Other types, which include CDs and removable media such as USB memory sticks, are considered ``slow''. Right, but I reme
Btw, Lisp strings are guaranteed to be NUL terminated, no need to create a copy to use is as a C string. Andreas. -- Andreas Schwab, address@hidden GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
I'm not sure I understand the difference. Could you give an example of a filesystem that's slow but not "remote (a.k.a. networked)"? Stefan PS: the criterion for file-remote-p is (C-h f file-remote-
Thanks. Already done by today's commits to the trunk. The function is called is_slow_fs, and returns non-zero if its argument resides on a filesystem deemed slow. I'm not sure this is what you want
Right. We didn't treat UNC file names as remote, it's as simple as that. I installed the patch below on the trunk. Stefan and Yidong, is it okay to install on the release branch as well? 2009-07-09
The code is written to effectively behave as if the variable was nil for remote filesystems. It just didn't handle UNC file names as remote. Now it does. Making the code faster (even beyond this bug
Yes (and it does). Doing that by default is too radical, IMO. Having this option non-nil on FAT/FAT32/XFAT has its merits, although less so than on NTFS. And the speedup for local drives would be mi
Network drives can be NTFS volumes as well, and usually are if the server is a Windows machine. But accessing all of the features we now support in file-attributes on Windows can be slow over the ne
I see (I think). I thought that the doc was saying that it should be non-nil only for NTFS, which should be independent of whether the file system is local or over a network.
I suggest we change the default value of this variable to nil (or make the code faster). Dumb question: Is there a way for Emacs to know whether the format is NTFS or FAT(32)? If so, then Emacs could
Dumb question: Is there a way for Emacs to know whether the format is NTFS or FAT(32)? If so, then Emacs could use nil for FAT volumes. (If not, it seems like nil would be the best default value.)
To clarify, I see 1 sec with Emacs 22.3, and 10 to 11 seconds with Emacs 23.0.95. Can you see if it's approximately linear in the number of files? That's somewhat strange. For me, the second time is
I did not have it set so it had the value 'local before I changed it to nil now. I googled for the variable now and saw this: "If the variable w32-get-true-file-attributes is non-nil (the default),
. Does it help to set w32-get-true-file-attributes to nil? Woooo! Um, yes... It helped all right. From 85 (first try) and 115 (second try as per reuest above), down to 1,4 s. Shall we call that as s
The more files there are, the bigger the slowdown seems to be, in my tests. Hehe, it got even worse the second time :) Woooo! Um, yes... It helped all right. From 85 (first try) and 115 (second try
Sorry for a long delay. I finally found a few minutes to look into this. First, I don't see a ~100-fold slowdown, I see only a 10-fold slowdown (vs Emacs 22.3). This is with a directory that has ~13
It should be much easier (and faster) if you use the git mirror and "git bisect". [e.g., "git clone git://git.sv.gnu.org/emacs.git"] -Miles -- Monday, n. In Christian countries, the day after the bas
Just so that I understand you correctly, are you suggesting I download and compile CVS emacs and do the "cvs up" trick and repeat this process until I get a compiled version that works? If so, it mi
Ouch! I'm quite sure I would have noticed such a terrible slowdown. Let me time similar commands tomorrow in my office. Not yet. But perhaps install StraceNT (http://stracent.en.softonic.com/) and s
Please use CVS. That lets you track down the problem with better granularity, and it's more convenient. See http://savannah.gnu.org/cvs/?group=emacs for a description of how to check out the cvs repo
I don't compile it myself, instead I rely on the precompiled pretests over at alpha.gnu.org. But maybe I will find the time to download them all and test, to narrow it down at least somewhat. Consid
If you have the time, try reverting to previous versions (e.g. `cvs up -Pd -D 2009-01-01') and find out which checkin introduced the problem. A binary search should narrow it down quite quickly.
I did all tests below in emacs -Q. //gbgfs1/archive75 is a share that contains 260 directories and three files. The server is located in our office. C-x d //gbgfs1/archive75 RET Emacs 22.1.1: 1 s Em
Please post some measurements (the original report says "a few seconds", which is quite vague) and the basic performance data of your machine. Also, please tell if this happens with every file, even
I understand that the release of 23.1 is not far away and I am a bit worried that this bug won't be solved before that. Is there anything I can do to help? I use a lot of UNC file names / paths in my
Not if your "date" changes less than 20 times per day. And in what way is that different from what happens if you choose the date based on the time the buffer is saved? I must still be missing somet
Depending on the user's preferences, all of the above. Also possibly by certain network activity. Then restarting emacs 20 times in one day will result in an unnecessarily large amount of files. So t
than what? What alternatives have you considered? How is the buffer-save triggered (is it triggered by a timer, by the user selecting the buffer and hitting C-x C-s, by some other command in the mai
Doing it this way allows people to store log files based on the date a buffer is saved, such as using a new log file each month, or day. Hooking into the save mechanism is a lot more straightforward
The rationale behind "" was that a non-zero string may be misinterpreted by a user/programmer as a real path, (Side issue reminder: please call it a "file name". In GNU we use the term "path" only fo
The rationale behind "" was that a non-zero string may be misinterpreted by a user/programmer as a real path, when its value would just be ignored. We could probably change ERC to name buffers with a
Why use "" rather than something else (since you say it's ignored anyway)? I suspect "" will create other problems than just with this new VC code. E.g. I wouldn't be surprised to see it bump into u
When a buffer has no file name, basic-save-buffer will prompt the user interactively for one. Since before-save-hook isn't run until after the interactive request for a file name, this prevents a hoo
Right. Other places in Emacs seem to expect that too (see get-file-buffer). Even so, it doesn't sound unreasonable to check that we're not calling string-match on nil, in any case... -- Romain Franco
See the commit message for erc-log.el rev. 1.7: The real problem is probably that buffer-file-name cannot be set in advance to the correct value since the filename will often be based on the date/tim
Hi Romain, Stefan, I can confirm this for ERC channel buffers as well, running with CVS erc and consider this a bug just like Stefan. Where is the use of "" as a value of buffer-file-name documented?
Hmm... I personally expect buffer-file-name to be an absolute file name (or nil). Admittedly, the docstring doesn't say that, so maybe your fix is indeed in order (or else the docstring of buffer-fi
This change is problematic for buffers where buffer-file-name is "" (like ERC server buffers in my case), file-name-directory returns nil so string-match signals an error. It makes it impossible to q
As explained, such a regexp will indeed stop VC from mucking around in // but it will do that *everywhere*, which is not what you want if your home directory is on //myserver/myhome since it means t
The above regexp does not work. The working regexp (when I try to open a file at '//wolfdei/d/users/dhruva/_emacs') is as follows: (defvar vc-ignore-dir-regexp "\\`\\([\\/][\\/]\\|/net/\\|/afs/\\)")
You can do it, Dhruva! If you look at the functions you changed (which are all prefixed with ;;;##autoload), you'll see that they are defined a second time (but this time not prefixed with ;;;##auto
I have reached the end (with my limited knowledge of elisp and vc). I will not be technically capable to do this, I request the elisp gurus to handle this and make this file opening speedup available
Sorry 'bout that. I disagree and I also disagree with the proposed docstring. We should document what the variable is meant for, not how it's used. It's meant for filenames which are interpreted by
Accept, the above looks much better. if I make a new patch and submit, will someone check it in? I have no write access. for other backends), vc-backend-registered is implemented for the new "backend
Also note that the suffix `-regexp' is both clearer and much more common (in emacs at least). :-) [and it looks those variables which _do_ use `-re' are almost all in code written by the same person.
In Emacs, a 'path' is something like load-path, and we never use the term 'path' for a directory name or file name. IMO, a better name would be something like `vc-ignore-file-re'. (defvar vc-ignore-f
Done the changes by putting the variable in vc-hooks.el with better documentation. I have used this patch and has worked with no issues so far. I request the patch to be reviewed and put into CVS hea
The problem is that network filesystems are not the real problem: If your home dir is accessed via NFS, you don't have to put it in that regexp. What needs to be in that regexp are the paths for whi
I don't think you should use the term "remote" here, it already has a specific meaning in Emacs not matching the intended meaning here. It should be made clear that this predicate is not just the opp
I meant the function name is somewhat similar to what we want but not the behavior. IMO, ideally in Emacs, something-p (like symbolp or functionp..) is used to test the argument, along the same line,
A directory is also a file, so file-remote-p should work also on directories. But file-remote-p does actually test something different, namely if you need a special method toaccess a file. IIUC an U
On Wed, 1 Sep 2004 15:20:03 +0530, Dhruva Krishnamurthy > I did some lookup into files.el, there is a function file-remote-p, I guess we should have a function dir-remote-p. This function can do a st
hello, Agreed. The whole chain started with my observation of very slowaccesstofiles under UNC when compared to XEmacs. In an earlier posting, I was told it was due to XEmacs using something like
That doesn't look right. If you want to ensure every backend sees the variable when needed, place it into vc-hooks.el (this is the always-loaded portion of VC). It needs to have a good doc string tho
Hello, This is a modified patch (original patch from Mr.KOBAYASHI Yasuhiro) including Stefan Monnier's suggested regexp. I do not know where to add the defvar "vc-hostname-fs-path-re" (currently, I h
On Mon, 30 Aug 2004 10:32:16 +0200, "Andreas Schwab" <address@hidden> said: After applying the patch, I do a 'make bootstrap' and I get an error reporting "vc-hostname-fs-path-re" not found. It is be
Hello, May be this was the regexp intended: (defvar vc-hostname-fs-path-re "\\`\\([\\/][\\/]\\)\\|/net/\\|/afs/") This works for me (tested for UNC only). I made a change to the patch to use the vari
When I use the above regexp in the earlier patch and try to open file: "//wolfdei/d/users/dhruva/_emacs", I get the following error: not: Invalid regexp: "Unmatched ( or \\(" I am not good in GNU Ema
The patch is basically "right", but only fixes one of the two (i.e. 2 of the 4) places. Also I think the problem is not limited toUNC paths, but might apply to any "global network filesystem" such
On Thu, 26 Aug 2004 16:52:47 -0400, "Richard Stallman" <address@hidden> said: I applied the patch sent by the author (Mr.KOBAYASHI Yasuhiro), did a 'make bootstrap', it did not work for me. I suspect
Wow! this works great. I am now able to see the behaviour I wanted to. Opening and saving are as fast as it would be with any local file. IMO, this patch _must_ get into GNU Emacs CVS soon so that al
'make bootstrap' is needed so that the patch effects the autoload section. find-file-hook is set vc-find-file-hook by default and finally vc-arch-registered or vc-mcvs-registered run. find-file-liter
Hello, I applied the patch (manually as I do not have a patch utility on win32). It does not seem to make a difference to me. Let me explain the steps I followed. 1. I manually applied the on to the
Maybe I found out the reason why slowaccess occured. '(file-directory-p "//{arch}")' or '(file-directory-p "//MCVS/CVS")' is executed in vc-arch-registered or vc-mcvs-registered even though '{arch}'
To the best of my knowledge, "/\hostname/sharefolder/file" is also treated as a UNC. Windows canonicalizes the file names before it passes them to the filesystem-related system calls, and as part of
This will also match a combination (2 nos) of forward and/or backword slash which is not correct. It shouldeither be 2 forward slashes or 2 backword slashes. Ex: A valid UNC can be either "//hostname
Hello, On Sun, 18 Jul 2004 11:49:12 +0200, "Andreas Schwab" <address@hidden> said: This (adding extra backslashes) is the main reason for all confusion. I personally feel PERL regex is more cleaner.
Emacs regexps already have most of the features PERL regexps provide, only with a slightly different syntax (more like BREs instead of EREs, different set of special characters) Andreas. -- Andreas S
You're right. Still not enough backslashes: (string-match "^\\(//\\|\\\\\\\\\\)" file) Remember that there are two levels of quoting: regexp quoting and string quoting, each adding it's own batch of