[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: I'd say that junction points were a great way to expose this feature under Win32 - after all, isn't it specifically what they were designed for? Incidentally, at least one other application uses them for exactly this purpose; a commercial source control tool named Accurev supports checked-in symlinks on Windows as well as *nix etc. The added advantage of junction points over whatever new API Vista exposes is that it'll work on at least XP (maybe even Win2K?) -- nosy: +swarren _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1578269> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] must run "make" before "make install"
Stephen Warren added the comment:
I can confirm this happens for me too, also on CentOS 5, with SVN 2.5
HEAD as of now.
It seems that this problem occurs, whilst running the first compileall
command for the libinstall target:
Compiling /somewhere/lib/python2.5/test/test_multibytecodec.py ...
Sorry: UnicodeError:
("\\N escapes not supported (can't load unicodedatamodule)",)
--
nosy: +swarren
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1704287>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] UnicodeError in compileall if "make install" is run before "make".
Stephen Warren added the comment: The attached patch should solve the problem by adding appropriate dependencies to the libinstall target. I have tested: ./configure; make install but not yet: ./configure; make all install ./configure; make all; make install Note: I introduced a new "build_all" phony target so that both all and libinstall could depend on this, rather than making libinstall either: * depend on all (which I guess would cause nasty looping dependencies if one were to run "make all install") * duplicate all the dependencies of all, thus causing a maintenance issue Possibly, the new dependencies should be added to install instead of libinstall? Alternatively, I guess one could make "all" touch a file, and "install" or "libinstall" validate that the file exists, and error out if it doesn't. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1704287> _ py_1704287.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704287] UnicodeError in compileall if "make install" is run before "make".
Stephen Warren added the comment: Now, I have also tested: ./configure; make all install ./configure; make all; make install The "install" piece of each of the above doesn't seem to accidentally duplicate any of the building work, so the patch seems to check out OK - no negative side-effects. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1704287> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: Hmm. I just tested Accurev - whatever it does, it works for files too. That said, it could be making hard-links, which I guess could be different. Additionally, the sysinternals "junction" utility doesn't find any junction points when probing the link files. I'll see if I can find out how they implemented it... _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1578269> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1578269] Add os.link() and os.symlink() support for Windows
Stephen Warren added the comment: It seems that Accurev uses junction points for directories, and hard-links for files. That's probably a little to disparate to implement in Python? Also, I tried sysinternals' junction.exe and whilst it allows one to create junction points that point at files, you can't actually read the file via the junction point - so it does seem that they only work for directories:-( Oh well, lets hope whatever new Vista API exists works better... _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1578269> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
New submission from Stephen Warren <[EMAIL PROTECTED]>:
Run the following Python script, on Unix/Linux:
==
import zipfile
z = zipfile.ZipFile('zipbad.zip', 'w')
z.writestr('filebad.txt', 'Some content')
z.close()
z = zipfile.ZipFile('zipgood.zip', 'w')
zi = zipfile.ZipInfo('filegood.txt')
zi.external_attr = 0660 << 16L
z.writestr(zi, 'Some content')
z.close()
==
Like this:
python testzip.py && unzip zipbad.zip && unzip zipgood.zip && ls -l
file*.txt
You'll see:
-- 1 swarren swarren 12 2008-07-17 12:54 filebad.txt
-rw-rw 1 swarren swarren 12 1980-01-01 00:00 filegood.txt
Note that filebad.txt is extracted with mode 000.
The WAR (used for filegood.txt) is to pass writestr a ZipInfo class with
external_attr pre-initialized. However, writestr should perform this
assignment itself, to be consistent with write. I haven't checked, but
there's probably a bunch of other stuff in write that writestr should do
too.
--
components: Extension Modules
messages: 69898
nosy: swarren
severity: normal
status: open
title: zipfile.writestr doesn't set external attributes, so files are extracted
mode 000 on Unix
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3394>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
Stephen Warren <[EMAIL PROTECTED]> added the comment: Oops. Forgot to set "type" field. -- type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3394] zipfile.writestr doesn't set external attributes, so files are extracted mode 000 on Unix
Stephen Warren <[EMAIL PROTECTED]> added the comment: I'd probably argue for at least 0660<<16, if not 0666<<16, since group permissions are pretty typically set, but even 0666<<16 would be OK, since the umask on extraction would take away any permissions the extracting user didn't want. But, as long as the chosen mask includes at least 0600, I'd consider the issue fixed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
